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1.0  SNYOPSIS  OF  THE  RESEARCH 
1.1  INTRODUCTION  TO  THE  PROBLEM 

In  the  past  quarter  century,  computer  technology  has  had  a profound 
impact  upon  the  manner  in  which  data  is  processed.  With  each  advance  in 
computer  hardware  technology  has  come  associated  advances  in  software 
capability  both  in  respect  to  the  processing  of  data  into  more  meaningful 
packets  and  in  the  management  of  the  computer  hardware.  A seemingly 
never  ending  cyclic  phenomenon  has  developed  with  regard  to  computer 
based  information  processing  systems.  Each  expansion  in  the  processing 
capabilities  only  increases  the  appetite  of  the  user  community  and 
consequently  new  demands  are  placed  on  the  system  designers  and  analysts 
to  increase  system  throughput,  reduce  response  time  and  provide  more 
services  while  maintaining  or  reducing  costs.  This  has  mandated  the 
better  utilization  of  expensive  computer  hardware  and  software  resources 
and  associated  personnel  and  thus,  the  development  of  complex  system 
architectures  incorporating  sophisticated  supervisors  to  handle  the  job 
scheduling,  task  management  and  resource  allocation  functions,  multi- 
processors to  increase  throughput  and  integrated  distributed  data  bases 
to  meet  the  user's  information  needs. 

Contemporary  computer  based  information  processing  system 
architectures  are  reflective  of  the  information  systems  they  support. 

As  the  information  needs  become  more  sophisticated,  so  does  the  computer 
system.  In  part,  this  phenomenon  is  the  result  of  new  technologies  which 
permit  increased  volumes  of  data  to  be  incorporated  into  information 
systems  at  reduced  operating  cost  and  faster  retrieval  time  per  quantum 
of  data  stored.  Unfortunately,  the  complexities  of  modern  society  have 
not  only  increased  the  enterprise's  need  for  information  but  also  the 
transiency  of  data's  value.  Furthermore,  needed  information  is  more 
integrative  in  nature  in  order  to  reflect  the  interdependencies  of 
modern  organizations.  Ill-designed  systems  which  do  not  meet  their 
operational  requirements  are  expensive  in  terms  of  the  time,  manpower  and 
dollars  lost  in  their  design  and  implementation. 
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The  design  and  analysis  problem  is  a complex  one,  and  its  complexity 
is  augmented  by  the  costs  associated  with  such  systems.  Furthermore, 
the  analyst  cannot,  in  most  cases,  rely  on  past  experiences  since  each 
system  must  be  tailored  to  the  particular  environment  in  which  it 
will  operate.  The  need  exists,  therefore,  for  modeling  technologies 
which  provide  the  analyst/designer  with  insights  into  the  behavior  of 
complex  on-line,  real-time  information  processing  system.  Additionally, 
such  technologies  must  be  attuned  to  the  descriptive  and  evaluative  needs 
of  the  information  processing  system  so  as  to  minimize  the  cost  and  effort 
for  their  use  both  with  regard  to  synthesizing  models  and  evaluating 
statistics  resulting  from  their  execution. 

Ideally,  models  provide  the  designer  and  analyst  with  the  ability 
to  identify  and  characterize  an  information  system's  user,  data  base, 
software  and  hardware  components  and  their  logical,  control  and  data 
interfaces.  During  the  lifecycle  of  an  information  system,  modeling 
activities  provide  a feedback  capability  to  the  designer  and  analyst 
which  enhances  their  ability  to  attain  and  maintain  performance 
objectives.  By  being  representations  of  systems  or  subsystems,  models 
serve  three  purposes  --  as  an  aid  to  design  by  providing  insight  into 
the  behavior  of  selected  system  components;  as  a predictor  of  performance 
changes  that  would  result  for  alterations  to  existing  systems;  and  as  a 
guide  to  monitoring  activities  by  identifying  components  to  be  monitored 
and  statistics  to  be  collected. 

Discrete  event  simulation  models  can  provide  a number  of  benefits 
to  system  designers  and  analysts.  They  can  also  be  expensive  endeavors 
which  remain  unused.  Among  the  important  benefits  to  be  achieved  from 
this  form  of  performance  assessment  are: 


1. 


2. 

3. 


Insight  gained  into  the  behavior  of  the  constituents  comprising 
a system, 

Identification  of  performance  sensitive  components. 
Identification  of  system  and  component  performance  in 
response  to  user  activity  (e.g.,  volume  and  mix),  and 
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4.  Estimates  of  performance  changes  which  would  result  from  new 
hardware,  software^,  and  data  base  architectures  and  system 
procedures . 

Simulation  models  serve  as  predictors  of  system  activity;  they  are  cost 
effective  only  when  the  costs  associated  with  model  synthesis,  validation 
and  evaluation  are  significantly  lower  than  the  cost  of  building  benchmarks 
or  prototype  systems. 

The  modeling  of  contemporary  systems  requires  the  inclusion  of 
submodels  for  data  base,  data  base  access  software  and  support  facility 
components.  Without  a systematic  and  modular  approach  to  the  total 
modeling  effort,  costs  can  become  prohibitive.  Therefore,  the  first  step 
in  achieving  a modeling  capability  is  the  identification  of  a set  of 
functional  components  common  to  the  information  processing  system 
architectures  to  be  investigated.  A second  requirement  for  a cost 
effective  modeling  capability  is  the  availability  of  models  which  permit 
the  analyses  of  alternative  architectures  and/or  system  activity  with  a 
minimum  of  modification.  Third  is  the  ability  to  incorporate  new 
evaluative  technologies  and  procedures  into  existing  models.  Fourth, 
simulation  models  must  produce  meaningful  statistics  from  model  evaluation; 
in  particular,  it  is  important  that  the  statistics  they  generate  are 
useful  to  the  analyst  and  designer  and  that  they  can  be  validated. 

Finally,  the  performance  assessment  system  should  allow  the  reuse  of 
component  characterizations  in  order  to  effect  technology  transfer  and 
thus  reduce  overall  cost. 

To  be  effective,  simulation  facilities  must  be  compatible  with  the 
designer  and  analyst's  evaluation  goals.  This  implies  the  ability  to 
perform  a spectrum  of  modeling  tasks  from  macroscopic  analyses  of 
preliminary  designs  to  detailed  assessments  of  instruction  execution 
characteristics.  Model  synthesis  must  be  consistent  with  the  informa- 
tion known  about  the  system  and  output  data  commensurate  with  the 


evaluation  needs.  Required  is  an  integrated  view  of  information  system 


'Software  includes  operating  system  modules,  application  programs  and 


general  data  base  access  software. 


activities  and  interfaces  which  permits  a top  down,  modular  approach  to 
model  synthesis  and  is  capable  of  accommodating  present  and  anticipated 
hardware  and  software  architectures. 

1 .2  RESEARCH  OBJECTIVES 

The  Information  Processing  System  Simulator  (IPSS)  has  been 
(21 

developed'  ' with  four  general  objectives  in  mind: 

1.  Ease  of  model  snythesis, 

2.  Modularity  in  model  construction, 

3.  System  self-containment,  and 

4.  Portability. 

Additionally,  it  is  recognized  that  the  system  must  maintain  executional 
efficiency  and  must  be  usable  by  a wide  spectrum  of  users,  from  the 
novice  to  the  sophisticate.  A continuing  goal  is  to  further  the  develop- 
ment of  IPSS  within  the  framework  of  the  above  objectives. 

The  purpose  of  this  research  was  to  investigate  methods  for  extending 
the  IPSS  language  and  statistical  facilities,  focusing  upon  those 
facilities  which  could  increase  the  definitional  and  evaluative 
capabilities  of  IPSS.  The  research  has  led  to  the  incorporation  of  new 
language  and  statistics  gathering  features  into  the  IPSS.  These 
include  (a)  DBMS  --  associated  definitional  statements  and  performance 
measures,  and  (b)  user  and  task-oriented  evaluative  capabilities  which 


provide: 

1 . 

Definitional  statements  to  ascertain  the  performance  of  a 
model  relative  to  user  goals; 

2. 

Definitional  statements  specific  to  network  and  hierarahical 
type  DBMS  archi tectures ; 

i 3- 

• 

Enhanced  standard  statistical  outputs  to  provide  additional 
insights  into  model  behavior;  and 

1 

i 

Interfaces  to  internal  model  facilities  thereby  permitting 

additional  model  control  and  statistics  generation. 

(2hpSS's  development  was  sponsored  in  part  through  research  grants 
GN-36622  and  SI S -7 5 -21 648  from  the  National  Science  Foundation. 

(Office  of  Science  Information  Services)  to  The  Ohio  State  University. 
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These  new  features  permit  modeling  activities  to  be  more  closely  identified 
with  actual  analysis  and  design  functions.  Additionally,  they  reduce 
model  antificiality  and  provide  more  meaningful  and  identifiable  statistics. 
The  benefit  to  the  modeler  is  a reduction  in  time  and  effort  required  to 
synthesize  and  validate  models  of  complex  information  processing  systems. 

1 .3  RESULTS  OF  THE  RESEARCH 

The  research  proposal  identified  modeling  constructs  and  statistics 
as  candiates  for  inclusion  into  the  IPSS  design  facility.  The  vehicle 
for  assessing  the  usefulness  of  these  extensions  was  the  modeling  of  a 
complex  system  architecture  to  be  described  in  Section  3.  Details  of 
the  evaluative  efforts  and  the  results  established  are  found  in 
Appendices  A,  B and  C. 

For  evaluative  purposes,  the  proposed  IPSS  extensions  were  placed 
tn  the  following  categories: 

A.  MODEL  STRUCTURE  RELATED 

1.  Data  Base  Subsystem  Submodels 

a.  IPSS  Data  Base  Access  Component 

b.  IPSS  Data  Base  Structure  Component 

2.  Newwork  of  Submodels  as  a Model 

B.  LANGUAGE  EXTENSION  RELATED 

1.  Data  Base  Subsystem  Definition 

2.  System  Effectiveness  Evaluation  Definition 

3.  Network  Definition 

C.  STATISTICS  RELATED 

1.  System  Effectiveness  Evaluation 

2.  Data  Base  Subsystem  Behavior 

3 . General 

In  Appendix  C the  results  of  the  evaluation  are  discussed.  In  all 
37  statements  and  123  statistics  identified  in  the  proposal  were  evaluated. 
The  results  of  the  evaluation  are  summarized  in  the  following  table. 


t 
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Table  1.3-1.  Summary  of  the  Evaluation  of 
Proposed  IPSS  Language  Extensions 


ASSESSMENT  CONCLUSION 


Not  Examined 
Examined  and  Rejected 

Examined  and  Found  to 

be  Useful  - 

Has  been  implemented 
as  proposed 

Has  been  implemented 
but  merged  into 
another  facility 

Has  been  defined  and 
not  implemented 

Has  been  defined,  used 
in  paper  model s , but 
not  implemented 


DISPOSITION 

CODE 


EU-IM 


EU-DP 


TOTAL 

Statements 

Statistics 

6 

20 

0 

0 

16 

0 

6 

7 

0 

93 

9 

0 

The  modeling  activities  also  demonstrated  the  feasibility  and 
suitability  of  applying  IPSS  and  its  underlying  methodology  to  the 
synthesis  of  models  of  complex  information  systems.  The  system  modeled 
to  demonstrate  these  capabilities  was  a host/back-end  processor  configura- 
tion which  supported  interactive  application  processing  and  a data  base 
management  system.  The  modeled  software  processes  included  a detailed 
characterization  of  application  loading,  DBMS  processing,  and  the 
operating  system  function  of  task  management,  job  scheduling  and  resource 
allocation. 

The  IPSS  methodology  proved  capable  of  providing  the  modeler  with  a 
modular,  top-down  approach  to  system  analysis  and  model  synthesis  thus 
facilitating  a solution  to  this  complex  problem.  Several  models  were 

constructed,  each  of  which  reflected  system  details  of  a particular  aspect 
of  the  system.  The  ease  of  model  expandability  in  both  breadth  and  depth 
was  demonstrated  through  the  construction  of  independent  models  and  their 
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Integration  into  an  overall  complete  model.  The  SIDPERS/IDMS  workload 
model  represents  the  software  processes  of  the  applications  and  IDMS  in 
detail  while  characterizing  the  operating  systems  and  computer  hardware 
as  black  boxes.  From  this  basic  model  , two  subsequent  models  were 
developed  by  splitting  the  software  processes  at  the  host/back-end 
interface  and  adding  characterizations  of  the  appropriate  hardware  and 
operating  system  software  functions.  The  synthesis  of  the  final  overall 
model  was  easily  accomplished  since  the  system  interfaces  were  clearly 
identified. 

These  models  were  independently  tested,  each  producing  a set  of 
statistics  reflective  of  the  modeled  processes  and  computing  environment 
In  all  cases  queueing  and  utilization  statistics  were  obtained  for  the 
modeled  software  and  hardware  resources.  These  statistics  provide  an 
easily  understood  synopsis  of  activities  since  one  or  more  IPSS  services 
were  used  to  represent  major  units  of  processing  (e.g.,  application 
programs,  TP  line  scheduling,  IDMS  processing).  Statistics  were  also 
automatically  collected  on  each  of  the  hardware  facilities  indicating 
both  potential  bottlenecks  and  under-utilized  components. 

The  models  were  all  internally  verified.  That  is,  through 
experimentation,  the  internal  processing  consistency  was  verified  to 
be  accurately  reflective  of  the  real  world  processes.  Due  to  the  lack 
of  operational  data,  however,  it  was  not  possible  to  validate  them 
through  comparison  to  actual  system  performance.  Thus,  although  some 
confidence  can  be  placed  in  the  relative  values  of  the  statistics 
reported  in  Appendix  B no  validation  has  been  made  with  respect  to 
the  magnitude  of  the  data  values. 

The  experiment  demonstrated  the  suitability  of  IPSS  to  model 
complex  systems  while  requiring  minimal  time  for  model  synthesis.  The 
modeling  effort  required  approximately  four  man  months.  The  resulting 
models  have  proven  to  be  versatile  as  well  as  adaptable  to  changing 

requirements  indicating  that  significant  portions  can  be  used  for 
other  application  areas.  For  example,  the  DMBS  and  operating  system 


processes  as  well  as  hardware  facilities  need  not  be  modified  when 
another  major  application  area  is  modeled,  thus  resulting  in  a 
substantial  reduction  in  future  related  modeling  efforts. 

In  addition,  this  experiment  has  served  to  focus  future  development 
work  as  well  as  to  validate  current  goals.  In  particular,  the  experiment 
demonstrated  the  need  for  simulation  facilities  specifically  attuned  to 
the  characterization  of  integrated  data  structures  as  represented  in 
IPSS/DBS.  These  initial  models  did  not  use  these  features  since  they 
were  not  fully  operational  , and  thus  the  logical  structure  of  the  data 
base  was  characterized  at  a more  abstract  level  than  desired.  Furthermore, 
experimentation  with  IDMS  record  mapping  policies  was  not  attempted 
because  of  the  complexities  involved  in  relation  to  the  time  available. 

A number  of  experiments  on  the  basic  models  became  readily 
apparent.  These  were : 

1.  Identification  of  the  maximum  number  of  terminals  which  could 
be  supported  as  the  system  approaches  saturation; 

2.  Response  time  behavior  for  system  processes  and  resources 
as  loading  increases  and/or  mix  of  transaction  types  is 
varied; 

3.  Effect  on  throughput  as  the  transaction  error  rate  is  varied; 

4.  Response  time  behavior  as  a function  of  transaction  arrival 
rate; 

5.  Effect  on  system  throughput  and  response  time  with  a m-way, 
multi -threaded  DBMS; 

6.  Impact  of  presorting  transactions  on  system  throughput. 

The  initial  model  did  not  contain  operating  system  or  computer  hardware 
characteristics.  However,  later  models  did  have  these  characterizations. 
Thus  the  effect  of  changes  in  their  characterizations  on  throughput  and 
response  time  could  also  be  examined  in  future  analyses. 

The  modeling  was  done  using  the  original  IPSS,  now  designated 
IPSS/BASIC,  The  IPSS/DBS  features  were  not  employed.  As  a result 
detailed  models  of  DBMS  behavior  could  not  be  easily  modeled.  However, 
paper  models  using  the  proposed  syntax  were  written  comparatively  quickly 
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(one  man-month  which  included  review  of  the  IDMS  literature),  This 
exercise  demonstrated  the  value  of  the  IPSS/DBS  capabilities  to  reduce 
the  modeling  effort  needed  to  characterize  DBMS  software  and  data  base 
scheme. 

Finally,  the  incorporation  of  the  IPSS/DBS  into  the  current  IPSS  has 

extended  the  concept  of  information  systems  modeling  into  the  area  of 

networks  of  simulation  models.  Since  the  IPSS/DBS  was  designed  to  execute 

either  as  a stand  alone  or  asynchronously  with  IPSS/BASIC  models,  it 

became  necessary  to  devise  a mechanism  to  accommodate  this  concept.  This 

(31 

mechanism  has  been  extended  so  that  an  arbitrary  collection  of  nodes'  1 
can  be  incorporated  into  an  IPSS  model . The  implementation  requirements 
for  this  concept  are  discussed  in  Appendix  C. 


^ An  IPSS  model  node  is  defined  to  be  an  uniquely  identified  submodel 
comprised  of  IPSS/BASIC,  IPSS/DBS  or  IPSS/BASIC -IPSS/DBS  components. 
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2.0  THE  INFORMATION  PROCESSING  SYSTEM  SIMULATOR  (IPSS) 


The  Information  Processing  System  Simulator  (IPSS)  is  a special 
purpose  digital  simulation  facility  designed  to  facilitate  the  performance 
assessment  of  complex  computer  based  information  processing  systems.  It 
represents  the  realization  of  a generalized  methodology  for  the 
performance  assessment  of  information  systems  and  has  been  designed  to 
be  applicable  to  every  phase  of  the  information  processing  system  life 
cycle.  Additionally,  models  developed  for  one  phase  can  be  easily  and 
inexpensively  modified  in  both  scope  and  depth  of  detail  . This  enables 
the  model  to  evolve  in  parallel  with  the  system's  progression  through 
Tts  lifecycle. 

The  methodology  employed  by  IPSS  divides  the  elements  of  an 
information  processing  system  into  three  categories  according  to  the 
function  they  serve:  data  bases,  services  which  access  the  data  bases, 
and  support  facilities.  As  illustrated  in  Figure  2-1,  a system  is  viewed 
as  a hierarchy  of  services  and  data  bases  with  each  level  supporting 
the  service  and  data  needs  of  the  next  higher  level  and  requesting 
support  from  the  adjacent  lower  level.  Performance  measures  identify 
the  behavior  of  services  relative  to  their  data  base  access  activity, 
acquisition  and  use  of  support  facilities,  and  use  by  other  services. 

The  methodology  emphasizes  data  base  access  activity  and  has  identified 
those  system  elements  at  each  data  base  level  which  contribute  to  this 
activity.  Within  IPSS,  the  characterization  of  system  elements  has  been 
formulated  in  a manner  such  that  their  interaction  during  model  evaluation 
automatically  produces  the  desired  performance  measures.  An  illustration 
of  the  modeling  process  is  shown  in  Figure  2-2. 

IPSS  is  more  than  a language  in  the  sense  of  a 6PSS  or  a SIMSCRIPT ; 
it  is  a complete  system.  In  addition  to  statements  defining  resources 
and  tasks  for  the  system  under  investigation,  IPSS  contains  special  state- 
ments  directing  the  IPSS  system  in  a number  of  auxiliary  functions 
including  the  use  and  management  of  user  defined  library  facilities, 
model  compilation,  and  model  execution  sequencing. 
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The  IPSS  language  facilities  have  been  carefully  designed  to  focus 
the  modeler's  synthesis  activities  on  the  IPSS  methodological  under- 
pinnings, In  this  manner  the  development  of  models  of  complex  systems 
can  be  done  in  a systematic,  top  down  manner.  This  affords  the  modeler 
the  same  advantages  that  these  techniques  provide  in  information  system 
analysis,  design  and  implementation.  Figure  2-3  illustrates  the 
three  phases  in  the  use  of  IPSS  for  IPSS  model  synthesis.  At  the 
begining  all  that  is  available  to  the  model er^  is  general  knowledge  of 
the  information  system  (at  some  stage  in  its  life  cycle).  Phase  I is 
an  implicit  one  during  which  the  modeler  employs  the  IPSS  methodology  to 
separate  overall  system  knowledge  into  specific  knowledge  of  the 
following  four  functional  components: 

A.  System  users  and  their  request  characteristics; 

B.  Services  to  be  provided  to  users  and  to  other  services, 
and  their  inter  service  connections; 

C.  Data  base  resources  and  configurations; 

D.  Hardware  resources  and  configurations. 

The  IPSS  language  has  been  specifically  formulated  to  characterize  these 
functional  components. 

During  Phase  II  the  above  functional  components  are  characterized 
via  the  IPSS  language  into  independently  defined  model  components. 
Presently  five  distinct  model  components  are  possible  to  describe  an 
information  system  as  shown  in  Figure  2-4.  (The  sixth  component,  the 
model  director,  is  used  to  control  simulation  activities  during  Phase  III, 
the  model  execution  phase.)  Not  all  are  required  to  model  a particular 
computer  facility.  Additionally,  more  than  one  of  each  component  (except 
model  director)  can  appear  in  an  IPSS  model  . A synopsis  of  the  role  of 
each  component  follows: 

1.  SYSTEM  RESOURCES  — contains  definitions  for  all  hardware,  software 
and  data  resources  comprising  an  information  system  model.  Included 
in  the  SYSTEM  RESOURCES  component  is  the  IPSS  supplied  clockwork 
mechanism  to  schedule  and  control  simulated  events  and  to  determine 

^A  modeler  is  assumed  to  be  a systems/analyst  or  a systems  designer. 
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when  the  simulation  is  to  terminate.  The  clockwork  logic  is  based 
on  the  next  most  inmediate  event  philosophy  for  controlling  discrete 
event  digital  simulations; 

STORAGE  STRUCTURE  — supplements  the  definition  of  data  set 
facilities.  It  provides  the  model  with  general  definitions  for 
data  set  files  in  terms  of  their  formats,  size  and  location 
relative  to  each  other  and  their  location  in  secondary  storage. 
Additionally,  the  STORAGE  STRUCTURE  component  is  used  to  define 
secondary  storage  space  management  policies  for  the  model  ; 

REQUEST  STREAM  — defines  the  external  requests  for  information 
system  services;  that  is,  the  users  of  the  system  being  modeled. 

The  modeler  is  required  to  define  types  of  users  and  their  inter- 
arrival times.  IPSS  converts  these  times  into  a composite 
arrival  time  stream; 

DATA  BASE  ACCESS  --  contains  the  definitions  of  all  the  resources 
required  by  the  DBMS.  These  include  the  hardware  resources  of 
buffers  and  user  work  areas  as  well  as  application  programs  and 
DBMS  software.  All  DBMS-related  entity  type  facilities  are  defined 
within  the  component.  DATA  BASE  ACCESS  is  similar  to  the  SYSTEM 
RESOURCES  component  in  that  it  contains  its  own  simulation  clock- 
work mechanism  similar  in  purpose  to  that  of  the  REQUEST  STREAM 
component, 

DATA  STRUCTURE  --  provides  the  modeler  with  a set  of  facilities 
which  allows  the  definition  of  logical  data  structures  and  the 
characterization  of  relationships  among  them.  This  can  be  applied 
to  a variety  of  DBMS  architectures  and  application  environments. 

The  DATA  STRUCTURE  component  permits  the  modeler  to  investigate  the 
effects  on  system  behavior  caused  by  alternate  set,  record  type, 
and  access  path  definitions.  The  definitional  facilities  provided 
enable  the  modeler  to  investigate  a wide  spectrum  of  logical  data 
structure  organizations  and  allocation  policies. 
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Also  Illustrated  in  Figure  2-4  is  the  division  of  the  IPSS  components 
into  two  subsystems  — IPSS/BASIC  and  IPSS/DBS^,  This  has  been 
done  to  permit  a modeler  to  concentrate  his  efforts  on  a particular 
aspect  of  the  problem.  Thus,  the  capability  to  model  only  the  data 
base  or  the  system  aspects  of  a total  system  is  provided  the  modeler. 

Associated  with  each  component  are  IPSS  language  facilities  which 
permit  the  modeler  to  define  and  characterize  information  system 
entities  and  attributes,  gather  statistics  and  control  model  behavior. 
Over  100  such  statements  are  available  to  the  modeler. 

The  function  of  Phase  III  is  to  assemble  the  model  , initiate  its 
execution  and  display  the  generated  performance  assessment  statistics. 
IPSS  provides  a modeler  with  a number  of  statistics  concerning  the 
behavior  of  modeler  defined  entities  and  IPSS  supplied  built-in 
information  system  services  These  statistics  fall  into  eight 
general  categories: 

1.  Operational  Statistics, 

2.  Request  Stream  Statistics, 

3.  I/O  Activity, 

4.  Queueing  Statistics, 

5.  Utilization  Statistics, 

6.  Wait  Statistics , 

7.  Service  Statistics,  and 

8.  Task/Activity  Statistics . 

Additionally,  the  modeler  can  employ  the  complete  facilities  of  the 
Fortran  language  to  develop  his  own  statistics.  Statistics  are  printed 
automatically  at  the  conclusion  of  each  model  simulation  unless 
explicitly  inhibited. 

^This  configuration  of  IPSS  components  is  currently  being  implemented. 
The  CSC  model  reported  here  employed  only  IPSS/BASIC  components. 
However,  the  IDMS  was  also  written  using  IPSS/DBS  facilities  but  has 
yet  to  be  validated. 

^These  services  are  characterizations  of  the  basic  I/O  operations  for 
tape,  DASD,  unit  record,  and  terminal  devices. 


Finally,  IPSS  contains  a library  facility  which  permits  the 
modeler  to  retain  previously  defined  models,  model  components  and  code 
segments  for  later  referral.  This  feature  can  greatly  reduce  modeling 
time . 

An  implicit  goal  of  the  IPSS  is  to  achieve  the  maximum  applicability 
of  the  methodology  and  the  IPSS  facility.  Therefore,  the  following 
criteria  have  served  as  guidelines  throughout  its  development. 

1.  Breadth  of  Applicability  --  the  ability  to  model  the  behavior  of 
contemporary  and  foreseeable  system  architectures  and  operating 
environment; 

2.  Functional  View  of  Systems  — the  ability  to  identify  and  characterize 
system  components  and  activities  based  on  their  function  independently 
of  a particular  architecture  or  environment; 

3.  Top  Down,  Modular  Model  Synthesis  --  the  ability  to  model  to  a 
level  of  detail  commensurate  with  the  desired  analysis  of  research 
objectives; 

4.  Extensible  Structure  --  the  capability  to  incorporate  new,  higher 
level  descriptive  facilities  and  performance  measures  into  the 
methodology  and  simulation  system;  and 

5.  Flexibility  of  Use  — the  ability  to  be  used  by  a wide  spectrum  of 
modelers  from  the  experienced  system  analyst/designer  and  researcher 
to  the  practitioner  and  student. 

Examples  illustrating  the  broad  flexibility  and  applicability  of  the 
extended  IPSS  system  follow. 

Model ing  Act ivi ties 

Modeling  activities  are  those  activities  concerned  with  the  development 
of  evaluative  capabilities  for  examining  the  behavior  of  existing  and 
proposed  software,  hardware  and  data  base  architectures. 

1.  Models  of  specific  data  base  management  systems  for  the  purpose 
of  examining  their  behavior  under  a variety  of  different  criteria 
such  as  loading,  data  structure,  and  data  mapping. 
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2.  Models  for  evaluating  the  influence  of  data  structures  on  system 
performance  over  a broad  spectrum  of  DBMS  loadings  and  support 
architectures . 

3.  Models  of  systems  where  the  central  site  computing  facilities  are 
comprised  of  computer  networks  in  order  to  examine  the  effects  of 
alternative  scheduling  and  tasking  philosophies. 

4.  Models  for  evaluating  the  interaction  of  front-end  and  back-end 
computing  capabilities. 

5.  Models  for  investigating  the  effects  of  queue  scheduling  policies 
for  basic  system  activities  such  as  job  scheduling,  task  manage- 
ment, resource  allocation,  and  paging  strategies  for  virtual  memory 
systems , 

6.  Models  to  evaluate  data  base  security  procedures;  in  particular,  the 
identification  of  authorized  users  to  the  system  and  the  impact  of 
such  activities  on  overall  performance. 

7.  Development  of  a simulation  capability  and  support  library  which 
permits  the  modeling  of  a wide  range  of  contemporary  architectures 
for  the  purpose  of  evaluating  new  technologies  as  they  become 
available. 

Performance  Measurement  Research 

Performance  measures  are  those  measures  which  assist  designers  and 

analysts  in  their  performance  evaluation  activities. 

1.  Measures  of  system  performance  based  on  user  oriented  goals. 

2.  Measures  of  the  impact  of  new  applications  on  current  systems. 

3.  Development  of  higher  level  measures  which  permit  the  identification 
of  critical  system  activities  based  on  applications  performance 
objectives . 

4.  Development  of  measures  and  procedures  which  aid  in  identifying 
(from  a set  of  alternatives)  the  "best"  alternative  to  achieve 
system  performance  objectives. 


5.  Development  of  measures  to  assist  the  data  base  administrator.  (.It 
is  assumed  that  data  base  administration  is  an  on-going  activity 
and  its  major  function  is  to  maintain  and  assure  the  integrity  of 
the  data  base  and  to  improve  its  performance  via  changes  in  its 
data  structure.) 

These  activities  were  possible  due  to  the  unique  design  of  IPSS  which 
permits  a top  down  modular  view  of  information  processing  systems  and 
the  special  language  constructs  and  facilities  developed  specifically 
for  the  above  purposes. 

The  IPSS  system  is  designed  to  analyze  information  processing 
systems  in  their  totality.  Initially,  IPSS  mechanism  for  the  defi- 
nition and  evaluation  of  hardware,  computer  system  software  and  storage 
level  data  structures  were  developed  and  have  been  extensively  tested. 

The  next  phase  in  the  continued  development  of  IPSS  was  to  incorporate 
features  for  the  description,  manipulation  and  evaluation  of  logical 
data  structures  of  the  kind  normally  encountered  in  modern  data  base 
management  systems.  While  the  current  IPSS  capabilities  substantially 
reduce  the  effort  required  to  model  system  and  data  base  level  software, 
hardware  and  dataware,  modelers  can  model  all  aspects  of  an  information 
processing  system.  A high  level  query  processing  capability  is  currently 
being  implemented  and  development  is  planned  for  a telecommunication 
specific  extension. 


The  main  goals  of  the  research  are  the  extension  of  tne  current 
IPSS  system  to  include  language  constructs  and  statistics  attur^d  to 
data  base  management  system  modeling  activities,  and  to  the  measurement 


of  system  performance  from  a user  perspective.  The  following  discussion 
provides  a background  to  evaluative  methodologies  asso.iated  with  the 
research  needs  for  these  areas. 


3.1  METHODOLOGIES  FOR  THE  EVALUATION  OF  USER  GOALS 
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As  the  complexity  of  current  and  anticipated  systems  increases,  the 
analyst's  need  for  more  sophisticated  evaluative  techniques  becomes 
more  apparent.  The  types  and  number  of  services  being  provided  by  an 
information  system  are  growing  rapidly.  Where  once  was  a homogenous 
set  of  similar  user  classes  which  could  be  evaluated  by  relatively 
simple  measures,  now  operates  a multitude  of  user  classes  and  services 
demanding  various  conflicting  performance  requirements  and  lacking  a 
single  common  measure  of  performance.  Thus,  from  an  external  performance 
point  of  view,  the  analyst  must  evaluate  information  systems  against  a 
multiple  set  of  user  criteria. 

From  an  internal  performance  view,  current  and  anticipated  demands 
force  the  analyst  to  also  evaluate  multiple  criteria.  As  the  number  of 
services  provided  increases,  the  size  of  the  delivery  system  must  also 
increase.  This  implies  that  the  number  of  resources  required  to  build 
the  system  will  increase.  Information  system  resources  — hardware, 
software  and  dataware  are  expensive  to  buy,  install  and  operate.  Thus, 
the  analyst  must  also  be  concerned  with  the  cost  effective  use  of  these 
resources . 

Current  evaluative  technologies  focus  on  only  one  criteria  in  the 
system  design  equation,  either  the  use  or  the  system's  resource  per- 

fromance,  The  ability  to  simultaneously  ascertain  the  impact  of  resource 
performance  on  user  goals  or  yice  versa  is  not  readily  achievable 
through  these  methodologies.  One  of  the  purposes  of  this  evaluative 
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expansion  is  to  establish  a formal  liaison  between  the  evaluation  of  user 
goals  as  a function  of  system  behavior  and  the  analysis  of  resource 
performance  as  a function  of  user  activity. 

User  oriented  analyses  with  objective  functions  based  on  response 
time,  throughput,  and  cost  have  been  (are  continuing  to  be)  reported  in 
the  literature.  Most  frequently,  analytic  approaches  use  queueing  models 
as  their  basis  (GAV76,  BUZ73,  KLE76  are  representative  of  this  type  of 
analysis).  Due  to  the  necessity  to  maintain  tractable  models,  many 
simplifications  are  required  for  a model's  analytical  solution. 

Simulation  models  have  also  been  applied  to  user  oriented  analysis  (C0N65, 
R0E70).  Unfortunately,  these  models  yield  only  average  and/or  aggregate 
measures  of  system  response.  As  a result  of  these  simplifications, 
the  analyses  produced  by  both  of  the  approaches  fails  in  many  cases  to 
identify  the  relationship  between  users  and  resources.  Therefore,  they 
are  suspect  when  used  to  predict  the  impact  on  system  performances  of 
modifying  the  current  environment. 

Alternatively,  performance  analyses  can  be  made  from  the  system's 
standpoint,  treating  the  user  and  his  goals  in  the  aggregate.  The  most 
common  approach  is  a subsystem  study,  where  a particular  part  of  the 
information  system  complex  is  isolated,  with  the  subsystem  user(s) 
represented  by  a stochastic  generator,  both  analytic  and  simulative. 

The  most  emphasized  areas  of  research  has  been  the  I/O  subsystem  (ABA68, 
NAH73,  BOU72)  and  CPU  utilization  (KLE72,  HEL70,  MLS76) . The  problem 
with  this  level  of  evaluation  is  that,  although  providing  valuable  local 
intuitive  insight,  these  models  rarely  relate  to  the  ultimate  information 
system  user,  and,  therefore,  do  not  provide  realistic  insight  into 
global  performance. 

Examinations  of  complete  systems  have  also  been  made.  Exhaustive 
hardware/ software  measurements  have  been  analyzed  by  Lindsay  and  Cole 
(LIN76,  C0L72)  while  simulation  models,  including  an  aggregate  user 
component,  have  been  built  by  Reeves  and  Pooch,  Norland,  and  Lum  (REE75, 
N0R71 , LUM70).  Alghough  results  of  the  evaluations  include  resource 
utilization  statistics  and  user  oriented  measures  such  as  response  time, 
there  is  little  attempt  in  these  models  to  relate  particular  resource 


usage  to  the  effort  on  user  goal  attainment.  But  from  practical 
experience  it  is  evident  that  there  is  indeed  a relationship  between 
user  goals  and  resource  usage.  In  fact,  Buzen  (BUZ76)  has  recently 
proposed  some  fundamantal  laws  for  computer  performance  which  relate 
resource  activity  to  global  system/user  measures  such  as  response 
time  and  throughput. 

Thus,  current  evaluative  efforts  have  not  been  able  to  provide  an 
acceptable  approach  to  handling  the  multiple  criteria  environment. 

Because  of  the  inherent  conflicting  nature  of  the  criteria  an  optimal 
design  is  not  possible,  and  therefore,  good  system  design  is  assumed 
to  satisfice  both  performance  related  criteria.  The  approach  embodied  in 
this  evaluative  expansion  was  to  first  establish  a casual  relationship 
(liaison)  between  user  goal  attainment  and  system  resource  activity. 

Then  after  measuring  the  resultant  behavior,  a multi-objective  technique 
was  employed  to  produce  a satisficed  evaluation.  The  liaison  will  be 
specifically  maintained  in  IPSS  via  the  Task  and  Activity  facilities. 

A mathematical  programming  technique,  multiple  goal  orooramming  (MGP) 
has  been  adapted  to  evaluate  the  multiple  performance  criteria  (CHN77). 

The  importance  of  providing  a task  modeling  capability  is  evident  by 
examining  current  multi -programming  system  design  philosophies.  There 
has  been  a continuing  trend  toward  hierarachic  design  of  operating 
systems  (DIJ68,  ZUR68,  MAD76,  SDB77),  both  top-down  and  bottom-up.  Such 
designs  imply  that  particular  functions  are  assigned  to  particular  levels 
within  the  hierarchy,  e.g.,  job  scheduling  at  one  level,  hardware  I/C 
control  at  another,  etc.  Each  of  the  functions  (levels)  also  in  a sense, 
manage  a class  of  resources  via  allocation,  usage  and  de-allocation.  In 
order  to  model  and  evaluate  the  effect  of  user  demand  on  each  of  these 
functional  levels,  and  thus,  on  their  subordinate  resources,  one  must 
be  able  to  model  the  tasking  function. 

The  overall  modeling  philosophy  of  IPSS,  coupled  with  the  addition 
of  the  TASK  and  ACTIVITY  facilities  allow  the  modeler  to  accomplish  this. 
The  purpose  of  the  TASK  facility  is  to  r.aintain  control  over  the  resultant 
resource  activity  with  respect  to  its  causal  user  demand.  This  resource 
activity  is  further  broken  down  by  activities  which  characterize  the 
individual  system  functions. 
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The  control  that  the  TASK  facility  exerts  over  its  subordinate 
Activities  and  resources  is  essentially  its  maintenance  of  statistics. 

In  IPSS  the  modeling  resource  usage  automatically  produces  an  extensive 
set  of  queueing  and  utilization  statistics.  The  characterization  of  soft- 
ware processing  also  produces,  automatically , service  by  service 
statistics  on  service  time  and  hierarchy  interactions.  The  TASK  facility 
is  associated  with  a particular  user  class  to  complete  the  user -resource 
liaison.  It  is  the  function  of  the  TASK  facility  to  maintain  a set  of 
statistics  measuring  the  behavior  of  its  subordinate  resources.  These 
statistics,  collected  dynamically,  essentially  partition  of  the  aggregate 
queueing,  utilization  and  service  time  statistics  to  each  causal  TASK 
(user  class).  Furthermore,  the  collection  and  maintenance  of  these 
statistics  is  performed  automatically  by  IPSS.  Thus,  the  first  part  of 
this  approach  to  information  systems  establishes  the  link  from  user 
demand  to  resource  activity  and  automatically  produces  statistics. 

The  second  part  of  the  approach  to  be  implemented  in  this  expansion 
is  an  evaluation  of  the  multiple  performance  criteria.  To  be  most 
effective,  this  evaluation  should  relate  resource  activity  to  user 
oriented  performance  goals.  This  entails  the  production  of  higher 
level  performance  measures,  that  may  not  be  solely  time  related  such 
as  cost.  This  completes  the  two-way  liaison  between  user  demand  and 
resource  activity  by  measuring  the  contributions  of  resources  to  the 
satisfaction  of  user  goals.  This  is,  in  part,  accomplished  via  the 
TASK/ ACTIVITY  liaison,  but  the  evaluation,  however,  is  performed  by  a 
multiple  goal  programming  based  procedure. 

The  evaluative  view  of  an  information  system  formulated  by  the  MGP 
procedure  is  identical  to  the  modeling  view  characterized  by  the  TASK 
and  ACTIVITY  facilities  whereas  using  the  TASK  and  ACTIVITY  aids  in  the 
creation  of  a top-down  modular  performance  evaluation  CPE)  model.  In 
fact,  the  variables  of  the  model  are  the  TASK  and  ACTIVITIES,  This 
analogy  was  designed  to  allow  the  automatic  collection  of  statistics 
by  the  TASK  facility  during  normal  modeling  be  directly  applicable  to 
the  PE  model  for  evaluation. 
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The  result  of  evaluating  this  PE  model  is  two-fold.  First,  the 
desired  evaluation  of  the  user  criteria  is  produced,  on  a global  goal 
basis  and  on  an  individual  goal  basis  (Task  basis).  Second,  each 
activity  is  also  evaluated  relative  to  its  service  time  performance, 
across  all  tasks  (user  classes).  This  evaluation  can  determine  if  a 
given  activity  is  being  under-utilized,  saturated  or  used  to  its  proper 
capacity,  where  proper  is  with  respect  to  all  tasks.  These  activity 
measures  can  be  used  as  guidelines  when  deciding  which  designs/ 
alternatives  to  follow.  The  most  probable  performance  inhibiting 
activities  can  be  identified  in  this  way.  An  overview  of  the  underlying 
methodology  of  this  multiple  criteria  evaluation  can  be  found  in  the 
paper  by  Chandler  and  DeLutis  (CHN77). 

3.2  METHODOLOGIES  FOR  THE  EVALUATION  OF  DATA  BASE  MANAGEMENT  SYSTEMS 

Sable  (SAB71)  outlines  a specific  evaluation  procedure  for  data 
base  systems  which  is  based  on  establishing  the  cost  effectiveness  of 
each  candidate  system  with  respect  to  a specific  problem.  He  proposes 
a mul tl stage  method  for  "scoring"  or  grading  DBMS  features.  The  scores 
are  normalized  according  to  an  assigned  nominal  requirement  for  each 
feature  and  multipled  by  a weighting  factor  which  represents  relative 
Importance.  The  overall  system  score  is  the  sum  of  the  weighted 
results.  This  methodology  relies  heavily  upon  the  intuition  of  the 
analyst  to  select  the  important  factors  and  to  assign  correct  weightings. 
In  addition,  it  presupposes  that  the  evaluation  data  are  available. 

While  methodologies  based  upon  this  approach  are  useful  for 
establishing  guidelines  and  controlling  the  overall  evaluation  process, 
they  are  static  in  nature  and  therefore  are  not  useful  in  measuring 
dynamic  DBMS  behavior.  However,  the  current  DBMS  literature  contains 
several  methodologies  specifically  designed  for  the  measurement  of  this 
type  of  behavior.  These  methodologies  all  provide  a set  of  descriptive 

facilities  for  the  definition  of  both  DBMS  software  and  computer  hardware. 
In  addition,  they  all  provide  a special  purpose,  discrete  event  simula- 
tion tool  for  the  analyst/designer. 
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Phase  II  (0WE70)  is  one  such  tool  for  modeling  hierarchical  base 
management  systems.  Its  objective  is  to  allow  the  modeler  to  study  the 
interaction  of  such  DBMS  variables  as  storage  structure  characteristics,  i 

data  distribution,  device  interaction,  and  access  methods.  The  modeler 
specifies  the  characteristics  of  the  data,  the  data  accessing  strategies, 
and  the  underlying  hardware  configuration  through  a special  purpose 
user-oriented  language.  Data  field  contents  are  characterized  by 
distribution  functions  and  data  fields  are  lelated  to  each  other  to 
form  what  is  called  segment  (the  logical  structure  of  the  data).  The 
logical  data  structure  is  then  mapped  to  a physical  storage  structure 
by  partitioning  the  records  into  files  which  exist  on  hardware  devices. 

The  accessing  strategy  allows  the  modeler  to  specify  the  lists  of 
records  which  are  to  be  accessed,  the  accessing  method  (i.e.,  sequential, 

indexed,  or  direct),  and  the  order  in  which  the  accesses  are  to  occur. 

. 

Phase  II  is  limited  to  the  I/O  analysis  of  single  level  hierarchical 
data  base  management  systems.  Its  design  objectives  are  intentionally 


modest  and  thus  it  is  not  suitable  for  modelling  more  complex  software 
interactions. 

A methodology  for  evaluating  data  base  scheme,  physical  data 
organization,  and  data  base  loading  is  described  by  Hulten  and  Soderlund 
(HUL76).  Their  simulator  is  called  ARTS/DB  (Analysis  of  Real  Time 
Systems/Data  Base  oriented  systems).  It  is  implemented  in  Simula  and 
executes  on  the  DEC10  system.  The  descriptive  facilities  which  they 
provide  allow  the  characterization  of  data  base  systems  in  terms  of 
CODASYL-DBTG  features.  An  ARTS/DB  model  consists  of  four  levels,  i.e., 
definitions  of  the  application,  the  DBMS,  the  system  software,  and  the 
hardware.  This  provides  the  analyst  with  a useful  mechanism  for 
performing  successive  experiments  with  only  slight  modifications  to 
the  model . 

A data  base  simulator  based  on  the  Data-Independent  Accessing 
Model  I (DIAM  I)  (SEN72)  has  been  developed  with  two  ojectives  in 
mind:  the  comparison  and  selection  of  existing  data  base  systems  and 
the  design  and  evaluation  of  new  data  base  management  techniques 
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(SCH76).  This  simulator  consists  of  four  subsystems  similar  to  the 
ARTS/DB  approach.  In  this  case  the  subsystems  correspond  to  the  levels 
of  the  DIAM  and  are:  a query  generator,  a query  translator  which  uses 
defined  access  paths,  and  I/O  generator,  and  the  host  computer  system. 

A three  stage  DBMS  model  building  approach  as  well  as  a simulator 
system  utilizing  this  approach  has  been  described  by  Reiter  and  Finkel 
(REI75,  REI76).  First,  high  level  user-supplied  logical  data  view 
descriptions  are  translated  into  an  intermediate  standard  form.  Second, 
an  instruction  stream  is  generated  which  refers  to  data  by  block 
address.  In  this  stage  no  assumptions  are  made  concerning  the  location 
of  data  in  physical  storage.  Third,  the  dynamic  elements  of  the  system 
are  employed  to  produce  performance  measures.  The  particular  DBMS 
under  study  is  parameterized  with  respect  to  data  representation, 
resulting  in  a specific  model  of  that  DBMS.  The  model  is  constructed 
of  static  and  dynamic  parts  which  results  in  a similarity  to  operational 
DBMS  and  also  in  executional  efficiencies. 

DeLutis  (DEL72)  presents  a methodology  for  the  analysis  of 


auxiliary  storage  systems  (AUXSIM).  In  this  system  the  modeler 
describes  hardware  devices  and  software  processes  using  language  state- 
ments which  are  highly  descriptive  of  these  devices  and  processes.  The 
AUXSIM  translator  produces  Fortran  source  code  which  executes  as  a 
discrete  event  simulation  of  the  system.  This  research  was  the 
predecessor  to  the  Information  Processing  System  Simulator  (IPSS).  The 
research  proposed  here  was,  in  part,  a further  extension  of  the  IPSS 
methodology  to  data  base  management  systems. 

In  addition  to  these  generalized  evaluation  techniques,  several 
specific  DBMS  models  have  been  developed  using  a variety  of  simulation 
languages  and  techniques.  The  primary  evaluation  criteria  used  by 
these  simulations  is  response  time  and  throughput. 

Ghosh  and  Tuel  (GH076)  designed  an  experiment  to  model  a large 
IMS  data  base  to  determine  the  effect  of  varying  such  DBMS  features 
• * as  the  retrieval  sequence  and  logical  data  structures.  They  collected 


operational  data  by  executing  IMS  in  a stand-alone  environment.  Their 
measurement  criteria  was  the  elapsed  time  required  to  execute  a 
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sequence  of  calls.  Griffith  (GR175)  constructed  a GPSS  simulation 
model  of  Univac's  DMS-1100  also  using  response  time  as  the  evaluation 
criteria.  The  simulation  results  reported  by  Nakamura  (NAK75)  include 
response  time,  resource  utilization  (cpu,  channel,  disk),  as  well  as 
statistics  related  to  transactions  and  queues.  Hall  (HAL74)  describes 
a DBMS  simulation  model  of  a hierarchical  data  base  whose  objective 
was  to  minimize  response  time  and  costs  to  the  user. 
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| 4.0  EXPERIMENTS 

A series  of  modeling  experiments  were  performed  between  mid  June 
and  mid  September  1977  for  the  purpose  of;  (a)  assessing  the  ease  of 
employing  the  IPSS  methodology  and  language  in  modeling  complex  systems, 
and  (b)  evaluating  the  usefulness  of  the  proposed  IPSS  language  and 
statistics  extensions.  The  system  modeled  was  an  on-line  real-time 
system  comprised  of;  (a)  data  entry  terminals;  (b)  a host  main  frame 
for  the  application  software  and  user  interface;  and  (c)  a CODASYL- 
like  data  base  residing  on  a backend  mini  computer.  Section  4.1 
summarizes  the  modeling  activities.  (.The  reader  may  refer  to 
Appendix  A for  a complete  discussion  of  each  of  these  models.)  The 
following  subsection  provides  background  as  to  why  such  a complex 
| ' system  was  chosen. 

The  purpose  of  the  experiment,  initiated  by  the  U .S , Army  Computer 
Systems  Conmand,  was  to  evaluate  a complex  information  system  architecture 
via  the  Information  Processing  System  Simulator  (IPSS).  The  primary 
objectives  of  the  experiments  were  three-fold: 

1.  To  demonstrate  the  capability  of  IPSS  and  its  underlying 

methodology  to  accurately  model  a complex  system, 

2.  To  ascertain  its  ease  of  use,  and 

3.  To  develop  a generalized  basic  model  of  the  following  systems: 

a,  an  interactive  version  of  the  SIDPERS  Personnel  system 
resident  in  an  idealized  Host  computer,  and 

b.  The  IDMS  data  management  system  resident  in  a PDP-11/70 
serving  as  the  back-end  computer; 

and  through  the  model  judge  the  appropriateness  of  the  proposed  IPSS 

language  and  statistics  extensions. 

Results  indicate  that  IPSS  is  well  suited  for  the  task.  Through 
the  use  of  a top  down  modeling  philosophy  a complete  model  of  the 
application  and  IDMS  processing  was  written  and  tested  in  less  than 
two  man  months  and  model  statistics  tracked  well  to  the  available  per- 
formance measures.  The  following  subsection  provides  an  overview  of 
the  salient  features  of  the  modeling  effort. 


- 30  - 


r 

1 1 


4.1  THE  MODELING  EFFORT 

The  purpose  of  the  modeling  activities  was  to  demonstrate  the 
feasibility  and  suitability  of  the  IPSS  to  model  large,  complex  informa- 
tion processing  systems.  Reflection  on  the  modeling  activities 
associated  with  the  SIDPERS/IDMS  experimentation  provides  positive 
evidence  that  the  IPSS  is  equal  to  the  task.  One  important  reason  that 
IPSS  achieves  its  goal  is  that  its  underlying  methodology  provides  a 
top  down,  modular  approach  to  system  analysis  and  model  synthesis  thus 
facilitating  answers  to  complex  analysis  and  design  questions. 

Several  models  were  constructed,  each  of  which  reflected  system 
details  suited  to  the  multi-stage  development  process  which  was  adopted. 
The  ease  of  model  expandability  in  both  breadth  and  depth  was  demonstrated 
through  the  construction  of  independent  models  and  their  integration  into 
an  overall  complete  model.  Appendix  A summarized  their  major  features. 

The  SIDPERS/IDMS  workload  model  represents  the  software  processes  of 
the  applications  and  the  IDMS  in  detail  while  characterizing  the 
operating  systems  and  computer  hardware  as  a block  box.  After  this 
basic  model  was  tested,  subsequent  models  were  developed  by  splitting 
the  software  processes  at  the  host/back-end  interface  and  adding 
characterizations  of  the  appropriate  hardware  and  operating  system 
software  functions.  The  synthesis  of  the  final  overall  model  was 
easily  accomplished  since  the  system  interfaces  were  clearly  identified. 

These  models  were  independently  tested,  each  producing  a set  of 
statistics  reflective  of  the  modeled  processes  and  computing  environment. 
These  results  are  summarized  in  Section  B.2.  In  all  cases  queueing  and 
utilization  statistics  were  obtained  for  the  modeled  software  and 
hardware  resources.  These  statistics  provide  an  easily  understood 
snyopsis  of  activities  since  one  or  more  IPSS  services  were  used  to 
represent  major  units  of  processing  (e,g,,  application  programs,  TP 
line  scheduling,  IDMS  processing),  Statistics  were  also  automatically 
collected  on  each  of  the  hardware  facilities  indicated. 
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The  modeling  activities  were  performed  with  approximately  six  man 
months  of  effort.  All  the  models  to  be  described  in  the  next  section 
were  completed.  However,  three  conditions  occurred  which  prohibited 
the  creation  of  the  sought-after  final  models.  These  conditions  were: 

1.  The  IPSS/DBS  parsers  were  not  completed  in  time  for  use.  However, 
models  of  the  data  base  reflecting  the  IDMS  scheme  have  been 
written  in  the  IPSS/DBS  syntax  and  semantics  specifications. 
Furthermore,  these  submodels  have  now  been  executed  under  the 
IPSS/DBS. 

2.  Combination  of  all  the  submodels  (excluding  the  IDMS  schema) 
could  not  be  successfully  compiled.  Investigations  into  the 
cause  of  the  problem  has  lead  to  the  detection  of  an  error  in  the 
IPSS  nucleus.  The  nucleus  did  not  detect  an  IPSS  library  manager 
message  signaling  the  lack  of  library  space.  Thus  model  code 
was  lost  and  was  undetected  until  final  model  assembly.  This 
condition  has  been  recently  fixed  and  the  models  have  been 
successfully  executed. 

3.  The  interfacing  mechanism  discussed  in  Appendix  C3  has  not  been 
completely  implemented.  This  is  due  to  the  unexpected  quantity 

of  code  which  had  to  be  modified.  Therefore,  the  IPSS  and  IPSS/DBS 
cannot  currently  execute  together.  This  problem  is  currently 
being  aleviated. 

Section  4.2  discusses  the  complete  modeling  program  envisioned 
for  the  modeling  experiment.  Appendix  B discusses  the  statistics  for 
the  submodels  actually  completed  during  the  experiment. 

4,2  SIDPERS/IDMS  MODELS 

The  purpose  of  this  section  is  to  provide  an  overview  of  the 
system  analysis  and  model  design  activities  related  to  the  IPSS  modeling 
of  the  Interactive  SIDPERS/IDMS  system/7^  For  analysis  purposes  the 
system  was  divided  in  the  following  logical  model  components: 


( ^The  IPSS  methodology  provides  a modular,  top-down  approach  to  system 
analysis  and  model  synthesis  thus  permitting  the  solution  discussed 
In  this  section. 


Hardware 


Host  machine  configuration 
Back-end  machine  configuration 


Software 


Operating  system  for  the  host  machine 

Operating  system  for  the  back-end  machine 

Terminal  interaction  modules 

SIDPERS  transactions 

Interface  modules 

IDMS 

These  logical  model  components  were  used  to  define  five  inter-connected 
system  activities  each  representing  specific  SIDPERS/IDMS  functions. 

This  organization  is  shown  in  Figure  4.2-1.  A number  of  models  were 
written  which  incorporated  a one  or  more  of  the  modeling  components 
and  represented  one  or  more  system  activities.  Figure  4,2-2  identifies 
the  submodels  and  incorporated  model  components. 

Because  of  the  magnitude  and  complexity  of  the  system,  a phased 
approach  was  taken  in  model  development.  The  model  synthesis  and 
validation  is  implicit  in  IPSS,  thus,  the  approach  posed  no  difficulties. 
In  Phase  I a model  of  the  SIDPERS  transactions  as  processed  by  IDMS 
(system  activities  1 and  5)  was  constructed.  However,  it  is  important 
to  note  that  the  entire  structure  of  the  final  model  was  represented 
in  this  preliminary  model.  This  was  accomplished  through  IPSS  services 
for  system  activities  2,3,  and  4 which  were  essentially  null  routines. 
That  is,  they  were  invoked  by  other  services  but  their  internal  processing 
function  remained  unspecified.  In  particular,  terminal  interaction  and 
secondary  storage  accesses  were  characterized  merely  by  advancing  the 
simulator  clock.  This  simplified  approach  allowed  the  SIDPERS 
transactions  and  the  IDMS  processing  functions  to  be  modeled  and  validated 

quikly.  Once  this  workload  flow  model  was  executing  successfully  and 
generating  statistics,  the  operating  system  and  computer  hardware  model 
components  were  added  in  succeeding  modeling  phases. 
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Figure  4.2-1  Structure  of  Final  SIDPERS/IPSS  Model 
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Phase  II  focused  on  the  host  environment.  The  base  model  was  system 
Activity  #1  as  represented  in  the  Phase  I model  with  the  backend  treated 
as  a black  box.  To  this  base  model  was  added  successively  more  detailed 
characterizations  of  the  host  system.  The  final  model  in  this  phase 
Included  the  characterization  for  the  backend  interface  hardware  and 
software.  A synopsis  of  Phase  II  activities  is  given  below.  Appendix  A2 
presents  detail  consideration  of  the  modeling  activities  in  this  phase. 

Phase  III  was  concerned  with  the  characterization  of  the  backend 
system.  Again  the  modeling  proceded  in  an  evolutionary  manner.  A 
sequence  of  models  was  planned  which  would  add  the  PDP  11/70  hardware 
and  operating  system  software  to  the  IDMS  workload  model  developed  in 
Phase  I.  For  these  activities  the  front  end  was  treated  as  a white 
box,  l.e,,  a external  source  of  back  end  requests.  Specifically  omitted 
was  any  attempt  to  model  IDMS  DML's  or  traversal  activities  for  the 
SIDPERS  logical  data  base  (as  defined  via  the  IDMS  DDL's).  These  latter 
functions  were  modeled  using  the  IPSS/DBS  facilities.  A synposis  of 
this  phase  is  given  below.  Details  are  found  in  Appendix  A3. 

The  goal  of  Phase  IV  was  to  combine  the  Phase  II  and  III  models 
into  a single  model.  As  mentioned  at  the  begining  of  this  appendix, 
a minor  IPSS  programming  error,  since  corrected  prevented  their  phase 
to  be  completed  within  the  scheduled  experimentation  time  line.  Results 
of  this  modeling  phase  will  be  reported  at  a latter  date. 

Phases  V was  planned  whose  purpose  was  to  model  the  IDMS  DML  's  and 
the  DDL  described  SIDPERS  data  base.  A paper  model  was  completed. 

However,  execution  was  delayed  until  completion  of  the  IPSS/DBS  parsers. 

As  with  Phase  IV  the  activity  was  completed  after  the  termination  of 
the  modeling  activities.  This  model  is  being  reported  in  Mr,  Brownsmith's 
disseration,  titled  "A  Methodology  for  the  Performance  Assessment  of  Data 
Base  Systems:  An  Extension  to  the  Information  Processing  System  Simulator 
Methodology",  which  is  to  be  available  Spring,  1979  from  Ohio  State 
University. 

The  goal  of  Phase  VI  was  to  integrate  the  Phase  V model  with  the 
final  Phase  IV  model.  Again  this  activity  has  to  await  modifications 
to  the  current  IPSS  and  IPSS/DBS. 
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A Synopis  of  the  Phase  II  Activities  (SIDPERS/HOST  Models) 

The  SIDPERS  application  model  was  built  assuming  a computer  free 
environment.  The  purpose  of  the  Host  submodel  was  to  provide  both  the 
hardware  configuration  and  the  operating  system  of  a host  computer. 

Since  no  particular  computer  system  had  been  identified  as  the  host 
computer  for  the  SIDPERS/IDMS  project,  a generalized  host  model  was 
constructed.  The  elements  of  this  model  were  characterizations  of 
those  operating  system  functions  that  support  the  SIDPERS  application 
and  the  Host/Back-end  interface.  These  include  the  job  scheduling, 
task  management  and  resource  allocation,  assumed  to  be  available  in 
the  Phase  I model,  were  now  characterized.  The  hardware  configuration 
that  was  modeled  consisted  of  only  these  hardware  components  required 
to  support  the  modeled  host  software. 

The  approach  to  construction  of  the  host  model  followed  the  premise 
that  the  host  operated  in  a reactive  mode.  The  existing  SIDPERS  model 
was  analyzed  and  when  an  operating  system  function  was  required,  a 
module  that  characterized  its  behavior  was  added  to  the  Phase  II  models. 
This  procedure  was  followed  for  all  levels  of  applications  represented 
in  the  SIDPERS  1,  and  for  the  Host/Back-end  interface  needs.  As  a 
result  a model  was  created  of  a host  computer  environment  that  satisfied 
the  SIDPERS  operating  needs.  The  operating  system  functions  included  in 
the  host  model  were  characterized  in  a general,  modular  parameterized 
manner,  such  that  at  a later  time,  the  mechanisms  of  the  functions  of 
a particular  host  computer  could  be  easily  incorporated  into  the 
existing  model.  Thus,  although  system  activities  1 and  2 were 
conmuni  eating  continuously,  modifications  to  the  latter  could  be  made 
without  affecting  the  existing  SIDPERS  application  model.  The  SIDPERS/ 
HOST  submodels  were  tested  by  "black  boxing"  the  back-end  machine. 

Synopsis  of  Phase  III  Activities  (BACK-END/ I DMS  Models) 

The  IDMS  model  was  built  like  the  SIDPERS  application  model  , assuming 
no  particular  computer  environment.  The  purpose  of  the  Back-end  system 
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model  was  to  provide  the  hardware  configuration  and  the  operating  system 
of  the  Back-end  environment.  Previous  Army  studies  had  designated  the 
PDP-11 /70  as  the  specific  computer  to  be  employed  as  the  back-end 
computer.  The  functions  of  this  computer  system  that  needed  to  be 
modeled  were  the  operating  system  functions  to  support  IDMS  and  Host/ 
Back-end  interface  routines.  As  with  the  host  submodel,  the  back-end 
submodel  was  assumed  to  operate  in  a reactive  mode,  responding  to 
requests  for  Its  services.  The  hardware  configuration  that  was  modeled 
was  the  complete  USACSC  PDR-11/70  configuration,  recently  moved  with 
AIRMICS  to  the  Georgia  Institute  of  Technology  in  Atlanta. 

The  back-end  models  were  built  modularly,  adding  chracteri sties 
of  operating  system  or  Interfacing  functions  as  they  were  needed. 
Although  these  characterizations  were  made  specific  to  the  AIRMICS 
PDP-11/70  computing  environment,  they  were  modeled  in  a parmeterized , 
modular  manner  so  that  if  different  PDP -11/70  strategies  were  to  be 
substituted,  the  IDMS  and  interface  submodels  would  not  be  affected. 

The  IDMS/Back-end  models  were  tested  using  the  SIDPERS  application 
model  as  the  work  load  generator. 

4.3  INSIGHTS  GAINED  FROM  THE  MODELING 

The  purpose  of  the  modeling  effort  reported  in  this  document  was 
to  demonstrate  the  feasibility  and  suitability  of  the  Information 
Processing  Systan  Simulator  (IPSS)  with  respect  to  modeling  large 
complex  information  systems.  The  system  modeled  to  demonstrate  these 
capabilities  was  a host/back-end  processor  configuration  which  supported 
interactive  application  processing  and  a data  base  management  system. 

The  modeled  software  processes  included  a detailed  characterization  of 
application  loading,  DBMS  processing,  and  the  operating  system  functions 
of  task  management,  Job  scheduling  and  resource  allocation. 

The  IPSS  methodology  provided  a modular,  top-down  approach  to 
system  analysis  and  model  synthesis  thus  facilitating  a solution  to 
this  complex  problem.  Several  models  were  constructed,  each  of  which 
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reflected  system  details  suited  to  the  multi-stage  development  process 
which  was  adopted.  The  ease  of  model  expandability  in  both  breadth 
and  depth  was  demonstrated  through  the  construction  of  independent 
models  and  their  integration  into  an  overall  complete  model.  The 
SIDPERS/IDMS  workload  model  represents  the  software  processes  of  the 
applications  and  IDMS  in  detail  while  characterizing  the  operating 
systems  and  computer  hardware  as  a black  box.  From  this  basis  model, 
two  subsequent  models  were  developed  by  splitting  the  software 
processes  at  the  host/back-end  interface  and  adding  characterizations 
of  the  appropriate  hardware  and  operating  system  software  functions. 

The  synthesis  of  the  final  overall  model  was  easily  accomplished  since 
the  system  interfaces  were  clearly  identified. 

These  models  were  independently  tested,  each  producing  a set  of 
statistics  reflective  of  the  modeled  processes  and  computing  environment. 
These  results  are  summarized  in  Appendix  B.  In  all  cases  queueing  and 
utilization  statistics  were  obtained  for  the  modeled  software  and  hardware 
resources.  These  statistics  provide  an  easily  understood  synopsis  of 
activities  since  one  or  more  IPSS  services  were  used  to  represent  major 
units  of  processing  (e.g.,  application  programs,  TP  line  scheduling, 

IDMS  processing).  Statistics  were  also  automatically  collected  on  each 
of  the  hardware  facilities  indicating  both  potential  bottlenecks  and 
under-utilized  components. 

These  models  were  all  internally  verified.  That  is,  through 
experimentation,  the  internal  processing  consistency  was  verified  to 
be  accurately  reflective  of  the  real  world  processes.  Due  to  the  lack 
of  operational  data,  however,  it  was  not  possible  to  validate  them 
through  comparison  to  actual  system  performance.  Thus,  although 
some  confidence  can  be  placed  in  the  relative  values  of  the  statistics 
reported  in  the  Appendix  B,  no  validation  has  been  made  with  respect 
to  the  magnitude  of  the  data  values. 

This  project  has  demonstrated  the  suitability  of  IPSS  to  model 
complex  systems  while  requiring  a minimal  time  for  model  synthesis. 

The  modeling  effort  as  reported  here  required  approximately  four  man 
months.  The  resulting  models  have  proven  to  be  versatile  as  well  as 


adaptable  to  changing  requirements  indicating  that  significant  portions 
can  be  used  for  other  application  areas.  For  example,  the  DBMS  and 
operating  system  processes  as  well  as  hardware  facilities  need  not  be 
modified  when  another  major  application  area  is  modeled,  thus  resulting 
in  a substantial  reduction  in  future  related  modeling  efforts. 

In  addition,  this  project  has  served  to  focus  future  development 
work  as  well  as  to  validate  current  goals.  In  particular,  this  project 
has  demonstrated  the  need  for  simulation  facilities  specifically  attuned 
to  the  characterization  of  integrated  data  structures  as  represented  in 
IPSS/DBS.  These  models  did  not  use  these  features  since  they  were  not 
fully  operational,  and  thus  the  logical  structure  of  the  data  base  was 
charcterized  at  a more  abstract  level  then  desired.  Furthermore, 
experimentation  with  record  mapping  policies  was  not  attempted  because 
of  the  complexities  involved.  Finally,  several  other  research 
endeavors  were  identified.  In  particular,  large  complex  models  of 
computer  networks  could  easily  be  constructed  from  models  of  individual 
nodes  if  a multi-simulator  approach  were  adopted.  Work  is  currently 
underway  to  allow  multiple  node  simulations  through  extension  of  IPSS 
facilities  and  concepts.  Extensions  for  modeling  teleprocessing 
activities  are  also  planned. 
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5.0  FUTURE  EXTENSIONS  TO  THE  IPSS 


This  research  activity  is  just  another  step  in  a continuing  IPSS 
research,  development  and  engineering  program  whose  goal  is  to  create 
a comprehensive  computer  aided  design  facility  appropriate  to  all  stages 
in  an  information  system's  lifecycle.  Three  steps  in  the  RD&E  plan 
have  now  been  completed.  These  include 

1.  1967  - 1972:  Initial  Methodological  and  Simulator  Development  - 

this  activity  resulted  in  the  Auxiliary  Storage 
System  Simulator  (AUXSYM).  Details  are  described  in 
"A  Methodology  for  the  Analysis  of  Auxiliary  Storage 
Systems"  available  from  University  Microfilms. 

2.  1972  - 1975:  Extension  to  the  methodology  and  complete  redesign 

of  the  simulator.  These  activities  resulted  in  the 
IPSS;  details  are  reported  in  "A  Methodology  for  the 
Performance  Evaluation  of  Information  Processing 
Systems"  (DEL77)  and  "The  Information  Processing 
System  Simulator  (IPSS):  Language  Syntax  and 
Semantics" . 

3.  1975  - 1977:  Continued  methodological  development  to  include 

the  following 

a.  DBS  specific  features; 

b.  Assessment  of  system  effectiveness  with  respect 
to  competing  user  goals; 

c.  Addition  of  mechanisms  to  determine  costing 
policies . 

d.  Assessment  of  system  loading  created  by  multi 
key  query  processing 

e.  Development  of  comparative  evaluative  techniques 
for  simulation  languages  vis-a-vis  performance 
assessment  needs, 

4.  1976  - 1979:  Verification  and  Validation  - The  purpose  of  these 

activities  has  been  to  demonstrate  the  effectiveness 
of  the  IPSS  as  a modeling  facility.  Validation  has 
included  paper  models  of  different  vendor  hardware 


software  and  file  structures,  models  of  idealized 
systems,  models  of  existing  complex  systems  (this 
report  describes  one  such  system.)  A proposal  by 
Chandler  is  designed  to  extend  this  activity  Into 
more  specific  validation  activities  where 
extrapolation  can  be  validated. 

As  a result  of  the  current  and  past  research  experiences,  an 
extensive  number  of  continuing  research  and  experimental  activities 
have  been  identified.  They  are  presented  here  to  illustrate  the 
potential  for  the  IPSS  and  its  underlying  methodology  and  to  Identify 
a means  of  activities  which  must  be  accomplished  in  order  to  achieve 
the  ultimate  research  objective  - that  being  to  create  a computer 
assisted  design  facility. 

A.  Extensions  to  the  IPSS  Methodology 

The  goal  of  these  research  activities  is  to  continue  the  extension  of  the 
methodology's  scope  of  applicability  to  (a)  higher  views  of  information 
system  processes  (b)  other  stages  in  the  information  process  system 
lifecycle  and  (c)  analysis  and  design  processes.  Five  research  activities 
have  been  identified  for  this  area.  They  are: 

1.  Teleconmunications  - extension  of  the  IPSS  the  permit  characterization 
of  data  comnunication  subsystems  in  a manner  familiar  to  their 
structure  and  behavior. 

2.  Requirement  Analysis  - extension  of  the  IPSS  to  interface  with 
requirements  analysis  methodologies  such  as  Tiechrow's  PSL/PSA  and 
TRW  Corp's  SCREM.^8) 

3.  Sensitivity  Analysis  - development  of  a methodology  which  permits 

the  assessment  of  models  to  identify  performance  sensitive  components. 

4.  Estimating  System  lifecycle  Costs  - development  of  a methodology  to 
examine  IPSS  models  for  the  purpose  of  (a)  estimating  the  number  and 
complexity  of  components  comprising  the  modeled  system,  and  (b) 
using  these  data  as  input  to  lifecycle  estimating  techniques. 

^PSL/PSA  is  acrynon  for  Problem  Statement  Language/Problem  Statement 
Analyzer  SREM  stands  for  System  Requirement  Engineering  Methodology. 


5. 


Automated  Component  Selection  - formulates  a methodology  which  is 
based  on  a predefined  view  of  system  components,  and  on  one  or  more 
design  criteria  will  automatically  alter  IPSS  models  thus  identifying 
feasible  designs  for  additional  analyses  by  the  modeler. 

B.  Extensions  to  the  IPSS  Language 

The  goal  of  this  development  activity  is  to  expand  the  model  synthesis 
and  statistical  display  facilities  of  the  current  IPSS  in  order  to  reduce 
modeler  effort.  Five  development  activities  have  been  identified.  They 
are : 

1.  Statistics  Generation  - development  of  language  extensions  to  cause 
the  automatic  gathering  of  standard  statistics  for  sequential 
("serially  reusable")  processes. 

2.  Verification  and  Validation  - extends  existing  and  develop  new 
statements  to  support  model  verification  and  validation  activities. 

3.  Operating  System  Characterizations  - extend  existing  and  develop  new 
facilities  attuned  to;  (a)  the  modeling  of  information  system  job 
scheduling,  resource  allocation  and  task  management  functions  and 
(b)  characterizing  main  memory  management,  CPU  interrupt  activity 
and  CPU  instruction  times. 

C.  Extensions  to  IPSS  Simulation  Facility 

The  purpose  of  these  activities  is  to  increase  the  ease  of  use  of  the 
IPSS  simulator  facility  by  the  modeler.  The  following  four  items  are 
proposed  as  extensions  in  this  area; 

1.  On-Line  Modeling  - extend  the  processing  environment  for  the  IPSS  to 
include;  (a)  on-line  entry  of  IPSS  language  statements  comprising  an 
IPSS  input  stream,  and  (b)  an  on-line,  real-time  prompter  facility 
to  guide  the  modeler  in  the  use  of  IPSS  language  syntax.  The 
modeler  will  be  able  to  switch  between  model  stream  definitions  and 
stream  processing  as  desired. 


2.  MACRO  Library  - the  IPSS  macro  and  library  facilities  currently 
permits  the  modeler  to  retain  models  and/or  model  components  for 
future  reference.  This  activity  would  develop  a set  of  generalized 
structures  presenting  the  salient  features  of  the  following  software 

a.  Operating  System:  task  management,  job  scheduling,  resource 
allocation  and  memory  management; 

b.  File  Utilities:  sort/merge,  file  copy,  and  opening  and  closing 
of  files; 

c.  Data  Base  Management  System:  buffer  management,  high  level 
DHL's , schema  structures. 

3.  Graphical  Display  - the  IPSS  would  be  enhanced  to  permit  graphical 
interaction  between  the  system  and  the  modeler.  Initially  this  will 
involve  only  output  of  items  such  as: 

a.  Model  statistics  including  frequency  listographics . 

b.  Model  structure  showing  the  network  of  services  described  for 
the  model  and  the  data  and  file  structures. 

c.  Dynamic  model  structure  showing  the  sequencing  of  service 
invocation  and  their  hierachy  during  a task's  execution. 

Ultimately,  the  goal  of  graphics  use  is  to  prove  a modeler/ system 
communication  interface  which  will  permit  interactive  support  of  model 
synthesis  and  the  display  of  model  structure,  model  verification  data, 
and  model  behavior  statistics. 
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APPENDIX  A 


BACKGROUND  TO  THE  MODELING  EXPERIMENTS 


The  objective  of  this  experiment  was  to  provide  a realistic  problem 
environment  against  which  the  IPSS  design  facility  (simulator  and 
methodology)  could  be  applied.  The  system  modeled  was  chosen  by  Mr. 

Allan  Curry  of  AIRMICS*  specifically  to  test  IPSS's  design  capabilities, 
ease  of  implementation,  and  adequacy  and  accuracy  of  the  resultant 
statistics.  The  chosen  system  architecturally  is  of  great  interest  to 
the  U.S.A.  Computer  Systems  Command  as  a replacement  for  exists  BASOP 
systems.  Section  A1  of  this  appendix  discusses  the  problem  environment 
including  a full  breakdown  of  the  hardware  and  software  characteristics 
of  the  system.  Section  A2  defines  the  IPSS  models  generated  to 
characterize  the  system. 

A1 . THE  PROBLEM  ENVIRONMENT 

The  purpose  of  the  following  discussion  is  to  provide  a background 
to  the  system  modeled.  The  system  modeled  evolved  from  a series  of  R&D 
efforts  performed  by  the  U.S.  Army  Computer  Systems  Command  (USACSC)  at 
the  request  of  the  Department  of  the  Army,  Director  of  Management 
Information  Systems  (DA  DMIS)  in  direct  support  of  their  "Vertical 
Installation  Automation  Baseline"  (VIABLE)  Project.  The  VIABLE  project 
was  established  to  upgrade  both  hardware  and  software  at  Army  data 
processing  installations.  Included  in  its  scope  is  the  competitive 
procurement  of  new  ADP  equipment,  and  the  extension  of  functional 
software  capabilities  to  include  management  information  system  require- 
ments as  well  as  interactive  processing. 

The  initial  USACSC  research  plan  was  developed  in  September  1975. 

Its  purpose  was  to  explore  and  demonstrate  those  technologies  which 

would  conceivably  be  utilized  in  Army  data  processing  systems  developed 

♦AIRMICS  stands  for  Army  Institute  for  Research  in  Management  Information 
and  Computer  Sciences. 


over  the  next  five  to  eight  years.  These  areas  included  on-line 
processing,  formal  data  base  management  systems,  mini  and  micro  computers 
and  distributed  data  processing  systems. 

One  aspect  of  the  plan  was  to  select  a single  functional  area  and 
build  a baseline  system  which  could  be  modified  repetitively  to  add  new 
features  and  migrate  from  one  environment  to  another.  The  Standard 
Installation/Division  personnel  System  (SIDPERS),  which  processes  Military 
Personnel  actions  was  selected. 

The  computer  system  modeled  was  composed  of  a Front  End  Module  (host 
machine)  which  processes  SIDPERS  transactions  in  a real-time  interactive 
mode,  attached  to  a Back  End  Module  utilizing  Cullinane  Corporations 
Integrated  Data  Base  Management  System  (IDMS)  to  interface  with  the 
personnel  data  base.  The  backend  machine  modeled  was  the  DEC  PDP -11/70 
System, 


A1 .1  SIDPERS 

SIDPERS  (Standard  Installation/Division  Personnel  System)  is  the 
batch  oriented  multi -command  personnel  data  processing  system.  It  is 
a large  system,  consisting  of  approximately  800  types  of  transactions 
which  perform  update  and  retrieval  operations  on  a personnel  data  base. 
However,  since  six  of  these  transactions  account  for  almost  eighty 
percent  of  the  total  transaction  activity,  only  these  transactions  were 
selected  for  incorporation  into  the  baseline  system.  These  transactions 
perform  the  following  functions:  adding  a soldier  to  the  data  base, 
establishing  duty  status  when  a soldier  arrives  at  an  installation, 
changing  the  duty  status  and  grade  of  a soldier,  deleting  a soldier 
from  the  data  base  on  departure  from  an  installation  and  acquiring  data 
on  a soldier  and/or  unit.  These  comnands  are  denoted  ADD,  ARRIVAL, 

DUTY  CHANGE,  GRADE  CHANGE,  DEPARTURE,  and  INQUIRY  respectively. 

The  SIDPERS  test  system  required  the  creation  of  a small  data  base 
of  sample  records.  Approximately  4,500  records  representing  12  different 
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record  types  were  selected  and  organized  into  an  IDMS  processable  data 
base.  The  details  of  this  data  base  and  its  organization  are  given  in 
the  next  section. 

The  SIDPERS  test  system  facilities  for  interactive  transaction 
processing  have  been  described  by  Schaaf  (SCH77)^.  Basically,  special 
terminal  interface  processing  modules  were  designed  which  allowed  a 
terminal  user  to  enter  the  above  transactions  in  either  a batch  or 
tutorial  mode  of  operation.  In  batch  mode,  all  the  data  for  a complete 
transaction  is  entered  at  once.  In  the  tutorial  mode,  the  terminal  user 
is  prompted  for  every  data  item  of  the  transaction.  This  requires  an 
access  to  a VALIDITY  record  which  contains  the  text  for  prompting. 

Items  that  fail  to  pass  the  validity  check  are  returned  to  the  terminal 
operator  for  re-submittal.  For  either  mode  of  operation,  once  all  the 
data  items  of  a transaction  pass  this  test,  the  corresponding  application 
program  is  invoked.  Essentially,  there  is  one  application  program  for 
each  of  the  transactions  listed  above.  As  part  of  application  processing, 
compatibility  checks  are  performed.  If  a data  item  doesn't  pass  this 
check,  several  accesses  are  required  to  correct  the  error;  namely  an 
access  to  a COMPATIBLE  record,  and  several  accesses  to  VALIDITY  records. 
Such  errors  cannot  always  be  resolved  and  in  these  cases  the  transaction 
is  terminated.  Otherwise  the  application  program  issues  a series  of 
DML  commands  to  the  IDMS  Modules  in  order  to  store,  modify,  and  retrieve 
records  in  the  data  base.  During  the  IDMS  Processing  of  each  DML, 
application  processing  is  suspended.  When  the  application  is  completed, 
control  is  returned  for  further  interaction. 


A1 .2  Prior  Analysis  Activities  of  SIDPERS 

t The  data  required  to  characterize  these  activities  was  provided  from 

a previous  study  of  VIABLE  transactions  (SHA77),  (.See  Tables  A1  .2-1 
■I  and  A1 .2-2  for  further  specifics),  This  document  provided  the  following 

data  for  each  of  the  six  types  of  transactions: 


I 


All  references  are  found  at  the  end  of  the  main  body  of  this 

report , 
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1.  the  relative  frequency  of  occurrence, 

2.  the  percent  direct  mode, 

3.  the  number  of  delta  items  per  transaction  entry, 

4.  the  percent  data  item  validity  error, 

5.  the  percent  data  item  compatibility  error, 

6.  the  time  for  direct  mode  data  items, 

7.  the  time  for  turorial  mode  data  items,  and 

8.  the  percent  of  transactions  canceled. 

This  data  was  incorporated  into  the  IPSS  model  of  SIDPERS/IDMS 
through  Fortran  DATA  statements  and  was  used  to  "drive"  the  model 
through  representative  terminal  sessions.  In  addition,  this  document 
contains  for  each  transaction,  a list  of  the  DMLs  that  are  invoked 
and  their  sequence  within  the  application  program.  This  data  was 
used  to  invoke  lower  level  DBMS  processes  as  described  in  the  next 
section. 

A1 .3  IPSS  Model  of  SIDPERS 

The  IPSS  SIDPERS/IDMS  transaction  model  was  designed  to  reflect 
the  arrival  validation  and  DML  activities  of  each  of  the  six  previously 
identified  SIDPERS  transactions.  Figure  A1  ,3-1  identifies  the  major 
functional  areas  of  this  model.  Each  functional  area  is  represented  by 
an  IPSS  service  or  services  within  the  model . The  function  of  each  of 
these  services  are  defined  as  follows: 

System  Loading 


Within  the  IPSS  model,  the  arrival  of  a transaction  at  a work 
station  is  represented  by  an  exogenous  event  (defined  within  the 
Exogenous  Event  Stream  Component),  This  event  was  scheduled  to  occur 
every  5,89  minutes  plus  or  mines  5 minutes.  This  is  based  upon  the 
following  assumptions  and  parameters.  First,  the  data  base  represents 
203  soldiers;  second,  that  there  are  an  average  of  8 transactions  per 
month  per  soldier;  third,  that  data  base  updating  activities  through 
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terminal  interaction  is  possible  8 hours  per  day,  20  days  per  month. 

These  figures  were  used  to  derive  the  transaction  arrival  event  frequency 
of  5.80  minutes.  The  deviation  of  5 minutes  was  selected  arbitrarily 
to  represent  variation  in  the  arrivals.  In  order  to  model  a larger 
data  base  or  different  arrival  patterns,  a single  statement  need  be 
changed  in  the  procedure  associated  with  the  event.  This  fact  is 
documented  within  the  procedure  and  the  statement  identified  for  ease 
of  modeler  experimentation. 

Transaction  Arrival  and  Sequencing 

This  service  represents  the  arrival  of  a transaction  at  a work 
station.  The  model  assumes  a single  terminal  and  hence  the  transaction 
may  be  queued  if  the  previous  one  has  not  completed.  The  model  also 
assumes  a FIFO  (first-in/first -out)  queueing  discipline.  The  time  that 
a transaction  waits  in  this  queue  is  a statistic  automatically  provided 
by  IPSS.  When  a transaction  is  selected  for  processing,  it  is  removed 
from  the  queue,  the  transaction  Selection  Service  is  invoked,  and  the 
service  waits  its  completion.  The  total  elapsed  time  from  transaction 
selection  to  completion  is  also  maintained  by  IPSS.  Upon  completion, 
the  next  transaction  is  selected  from  the  queue  and  the  service  becomes 
idle.  Idle  time  and  busy  period  statistics  are  also  kept.  All  the 
statistics  mentioned  above  are  maintained  for  each  of  the  services 
and  will  not  be  further  documented  in  this  section. 

This  service  can  easily  be  modified  to  reflect  an  arbitrary  number 
of  terminals  simply  by  establishing  the  maximum  number  of  terminals 
permitted  to  be  in  operation  at  once,  and  keeping  track  of  the  current 
number.  Only  those  transactions  which  arrive  when  the  current  number 
is  equal  to  the  maximum  number  need  by  queued.  An  infinite  number  of 
terminals  can  be  modeled  simply  by  not  comparing  these  two  variables 
and  hence  never  queueing  a transaction. 
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Transaction  Selection 

This  service  selects  the  type  of  transaction  that  has  arrived  and 
associates  with  it  a set  of  parameters,^  The  selection  is  made  by  a 
probability  distribution  function  based  on  relative  frequency  data 
provided  by  the  Schaaff  (SCH77)  study.  Once  this  selection  is  made, 
this  service  invokes  the  terminal  interaction  and  validation  service 
and  waits  for  its  completion.  When  the  processing  associated  with  this 
lower  level  service  has  completed,  the  Transaction  Selection  Service, 
determines  if  the  transaction  has  been  canceled  (via  a return  code)  and, 
if  not,  invokes  the  proper  Application  Service  and  waits  for  its 
completion. 

Terminal  Interaction  and  Validation 

This  service  represents  all  the  activities  associated  with  the 
entry  and  validation  of  a transaction  by  a terminal  operator;  and  can 
be  conceptually  divided  into  two  parts,  namely  those  activities  that 
occur  in  obtaining  valid  transaction  through  terminal  interaction  in 
direct  mode  and  those  activities  required  to  process  and  complete  the 
transaction  in  tutorial  mode.  These  processes  are  both  characterized 
through  tabular  data  and  probability  distribution  functions.  Input 
from  the  terminal,  for  example,  is  represented  by  advancing  the 
simulator  clock.  In  separate  models,  facilities  representing  the 
hardware  and  software  processes  are  characterized  and  thus  these 
activities  are  more  accurately  measured.  The  tutorial  input  mode 
requires  several  more  parameters  than  the  direct  mode  to  characterize 
the  events.  The  final  activity  of  this  service  is  to  determine  whether 
the  transaction  is  to  be  canceled.  This  is  communicated  to  the 
invoking  service  by  a parameter  value. 

TXV  ’ - - » ^ - 


These  parameters  represent  the  transaction  characteristics  and  are 
derived  from  the  data  in  Tables  Al.2-1  and  A! .2-2. 
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Application  Services 

The  model  contains  a set  of  six  functionally  similar  services, 
each  of  which  represents  the  processing  performed  by  an  application 
program  for  one  of  the  transactions.  These  services  are  all  invoked 
by  the  Transaction  Selection  Service  and  they  all  at  some  time  invoke 
the  IDMS  Interface  Service.  The  processing  performed  by  these  trans- 
actions is  represented  by  a series  of  DML  invocations  to  this  lower 
level  service.  The  internal  data  manipulation  activities  are  not 
represented  in  the  model  since  their  impact  on  performance  is  assumed 
to  be  minimal.  The  DMLs  are  identifical  in  type  and  sequencing  to 
those  reported  by  Schaaf  (SCH77);  their  format  is  further  discussed 
in  the  next  section. 

While  not  all  performance  evaluations  characterize  application 
processing  to  the  detail  represented  in  this  model,  this  approach 
was  deemed  best  for  this  model  for  the  following  reasons:  (1)  the 
data  was  readily  available,  (2)  the  mechanics  of  model  construction 
was  facilitated  by  IPSS  language  modeling  features  and  (3)  the  model 
architecture  emulates  the  processing  performed  by  the  real  system. 

Thus,  when  the  model  is  used  in  the  future  it  will  be  evident  what 
processes  are  being  modeled. 

Within  IPSS,  a service  is  dynamic  facility  and  as  such  statistics 
are  automatically  collected  for  its  use.  For  each  of  the  services 
identified  in  Figure  A1 .3-1,  utilization  statistics  are  produced.  These 
include:  busy  period,  idle  period,  concurrency,  seizure,  and  transaction 
transmit  time  statistics.  In  addition,  queueing  statistics  are  also 
produced.  However,  because  of  the  nature  of  the  model,  only  the 
Transaction  Sequencing  Service  has  queueing  associated  with  it.  These 
queueing  statistics  include:  busy  period,  idle  period,  queue  length, 
queue  entry,  and  transaction  transmit  time  statistics. 
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DEC  PDP  11/70  (DATA  BASE  MAChINE) 

INTEGRATED  DATA  BASE 
MANAGEMENT  SYSTEM  (IDMS) 


Figure  A2-1  Experimental  Version  of  VIABLE  SIDPERS 
Processing  Environment 
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A2.  THE  HARDWARE/SOFTWARE  ENVIRONMENT 

The  configuration  established  as  the  protype  for  the  VIABLE  SIDPERS 
project  employs  the  host/backend  concept  (Figure  A2-1).  The  IDMS 
SIDPERS  data  base  would  reside  on  and  be  controlled  by  the  backend 
machine.  The  purpose  for  this  structure  is  to  reduce  the  load  on  the 
host  machine  in  order  to  extend  the  life  of  the  mainframe.  Previous 
studies  have  not  designated  a particular  host  machine  for  use  by 
USACSC.  Currently,  the  VIABLE  SIDPERS  test  data  base  is  maintained  on 
the  USACSC  HCC  IBM  370  system,  with  both  host  and  backend  machines 
residing  there.  One  of  the  most  immediate  applications  of  the  models 
developed  during  this  project  is  to  evaluate  different  host  environments, 
in  particular,  the  IBM  370  environment  versus  the  PDP-11/70  environment. 
Thus,  the  goal  of  the  modeling  effort  with  respect  to  the  host  machine 
is  to  develop  a model  of  a machine  independent  generalized  host  machine, 
allowing  for  each  substitution  of  environments. 

A2 .1  The  Host  Machine 

To  accurately  model  the  IBM  370/165  host  was  deemed  to  be  too 
time  consuming  a task  with  regard  to  the  objectives  of  the  project. 
Therefore,  an  idealized  host  environment  was  identified  which  paralleled 
the  hardware  and  software  needs  of  the  VIABLE/SIDPERS . Host  hardware 
is  shown  in  Figure  A2.1-1,  It  included  the  terminal,  CPU,  secondary 
storage  equipment  (I/O  Processor,  disk  control  unit  and  eight  IBM  3330 
type  disk  units),  and  a data  channel  to  the  backend  machine.  Also 
shown  in  this  figure  are  the  hardware  components  assumed  for  the 
backend  computer. 

Host  software  functions  jn  addition  to  the  SIDPERS  are  shown  in 
Figure  A2.1-2,  The  major  components  of  the  application/host  environment 
are  the  teleprocessing  (TP)  Interface  with  the  user,  the  TP  interface 
with  the  backend  machine,  the  host's  disk  1/0  software,  and  the  SIDPERS 


! 


SIDPERS  APPLICATION 


Figure  A2.1-2  Modeled  Host  System  Resident  Software 


application  itsel*  The  generalized  host  operating  system  (OS)  is 
assumed  to  be  r in  operation,  i.e,,  executing  only  to  respond  to 

the  needs  of  the  ir  software  components. 

Since  VIABLE  SIDPERS  is  interactive,  communication  with  the  user 
is  maintained  throughout  each  step  in  the  process.  In  this  capacity, 
the  host  performs  the  function  of  scheduling  the  communication,  managing 
the  TP  line  and  sending/receiving  the  messages.  After  the  initial  log-on 
procedure  the  host  operating  system  schedules  the  initiation  of  SIDPERS 
processing.  The  input  and  validation  of  SIDPERS  data  involves,  in 
addition  to  the  host's  TP  functions,  disk  I/O  for  the  purpose  of 
retrieving  error  messages  for  transmission  to  the  terminal  . 

The  crucial  element  of  this  model  is  the  liaison  between  the 
application  in  the  host  machine  and  the  DBMS  in  the  backend  machine. 

The  DML  request  must  be  transmitted  to  the  backend  for  processing  and 
the  retrieved  record  must  be  received.  To  accomplish  this,  the  host 
supports  an  interface  subsystem  which  formats  the  DML  request,  reformats 
the  resultant  record,  handles  the  asychronous  transmission  and  reception 
of  messages  to  and  from  the  backend,  and  controls  the  necessary  devices 
for  this  communication  link.  It  is  assumed  that  each  of  the  host  modules 
rely  on  the  basic  operating  system  functions  of  task  management  and 
resource  allocation.  As  in  the  actual  system,  the  performance  of  these 
host  functions  is  transparent  to  the  processing  of  the  application. 

In  order  to  make  the  model  of  the  host  environment  machine 
independent,  several  conventions  were  employed.  When  scheduling  was 
required  (Job,  disk,  or  I/O),  a FIFO  queue  was  assumed  for  that  host 
module.  Resource  allocation  algorithms  for  TP  and  IOCS  needs  were 
also  assumed  to  be  FIFO.  Any  algorithm,  however,  can  be  substituted 
by  changing  only  the  host  scheduling  services  without  effecting  the 
model's  application  services. 


A2.2  The  Backend  Machine 


The  particular  computer  system  selected  by  USACSC  for  the  backend 


detailed  and  specific  model  could  be  built.  The  hardware  configuration 
for  the  existing  USACSC  AIRMICS  PDP-11/70  was  modeled,  Secondary 
storage  characterization  conformed  to  the  1DMS  a fixed  page  environment, 
i.e.,  the  physical  data  records  of  the  data  base  with  a page  size  of 
1,024  bytes  and  a direct  file  organization.  Figure  A2.2-1  shows  the 
hardware  configuration  modeled. 

The  crucial  aspect  of  modeling  the  backend  machine  for  this  project 
was  to  identify  and  characterize  the  interactions  between  the  PDP-11/70 
operating  system  and  the  IDMS  applications.  The  main  application  oriented 
functions  to  be  coordinated  by  the  resident  PDP-11/70  OS  are  illustrated 
in  Figure  A2.2-2,  The  internal  functions  of  the  backend  machine  are 
essentially  the  same  as  the  generalized  host  except  for  UNIBUS  management. 
The  concept  of  the  UNIBUS  (a  bidirectional  data  path  through  which  all 
resources,  including  CP  and  memory,  communicate)  is  central  to  PDP-11/70 
processing.  But  its  effect  on  processing  is  transparent  to  the 
application.  The  backend  PDP-11/70  has  an  interface  in  the  host. 

Because  the  PDP-11/70  is  not  dedicated  to  data  base  applications,  and 
because  USACSC  has  plans  to  support  more  than  one  data  base  per  backend 
machine,  each  invocation  of  IDMS  is  treated  as  a separate  subtask.  The 
problem  of  concurrent  updating  by  multiple  users,  however,  forces  the 
need  for  a single  entry  point  or  interface,  called  CAMP  (Central  Access 
Monitor  Program).  Even  though  entry  to  IDMS  is  controlled  via  the 
application,  the  actual  operation  of  IDMS  necessitates  many  requests 
for  task  management,  resource  allocation  and  I/O  control  . The  model 
of  the  PDP-11 /70  operates,  as  was  assumed  for  the  model  of  the  host 
machine,  in  a reactive  mode. 

The  object  of  the  IDMS  processing,  retrieval  of  the  specified 
physical  record,  necessitated  the  scheduling  and  use  of  I/O  hardware 
which  comes  under  the  preview  of  the  PDP-11/70  analog  of  the  host's 
disk  I/O  module.  Passing  retrieved  records  to  the  host  requires  the 
aid  of  the  OS  to  handle  the  sequencing  of  completed  IDMS  tasks  and 
de-allocation  of  resources. 


Figure  A2.2-1  USACSC  PuP  11/70  Configuration 
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The  job  and  task  scheduling  disciplines  employed  by  POP -11/70  OS 
are  priority  queues  based  on  the  immediacy  of  use  of  the  UNIBUS  and 
were  so  modeled.  All  tasks  performed  by  the  PDP-11/7Q  priority  scheme 
resulted  in,  essentially,  FIFO  queues. 


A2.3  Integrated  Database  Management  System  - IDMS 


• | 


The  Integrated  Database  Management  System  is  a network  oriented 
implementation  of  a subset  of  the  1971  CODASYL  Database  Task  Group 
specifications.  The  following  activities  were  involved  in  making  the 
conversion  from  sequential,  batch  processing  to  the  IDMS  on-line 
integrated  database.  First,  the  architecture  of  the  integrated  structure 
of  the  database  was  determined.  Each  of  the  files  identified  in 
Figure  A2.3-1  became  (in  IDMS  terminology)  "record  types"  whose  intercon- 
nections are  represented  by  "sets".  Second,  the  COBOL  application 
programs  for  the  six  transaction  types  was  rewritten  to  reflect  IDMS 
processing.  The  major  impact  was  in  the  incorporation  of  a centralized 
description  of  the  database  and  in  changing  the  I/O  statements  to 
standard  IDMS  Data  Manipulation  Language  (DML)  commands. 

IDMS  performs  the  following  functions  in  response  to  an  application 
DML.  First  it  validates  the  request  using  the  sub-schema  definitions. 
Next  it  translates  the  request  into  a virtual  page  reference,  determines 
if  the  page  is  present  in  its  internal  buffer,  and  requests  the  page  from 
the  underlying  file  management  system  when  it  is  not  already  present. 
Finally,  it  places  the  subschema  record  into  the  application's  work 
area  and  returns  control  to  the  application, 

IDMS  has  its  origins  at  the  B.F,  Goodrich  Company  where  it  was 
initially  developed.  The  Cullinane  Corporation  (Wellesley,  MA)  now 
maintains  product  responsibility,  IDMS  operates  on  IBM  360/370 
hardware.  In  addition,  it  is  available  through  the  Digital  Equipment 
Corporation  as  DBMS-11  which  operates  on  PDP-11/70  hardware. 

The  following  paragraphs  briefly  introduce  the  major  IDMS  system 
components  which  were  incorporated  into  the  IPSS  model  (CUL76): 
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Data  Description  Language  (JDPL)  — A facility  for  describing  data 
independent  of  the  programs  that  process  it,  Within  IDMS  the  DDL 
consists  of  three  parts: 

1.  Schema  DDL  — provides  a complete  description  of  the  database 
including  names  and  attributes  of  all  data  items,  records,  sets,  and 

i ■ 

areas. 

2.  Device  Media  Control  Language  (DMCL)  — provides  control  over  all 
the  disk  files  which  are  to  be  on-line. 

3.  Subschema  DDL  --  provides  a description  of  those  data  items,  .j 

records,  sets  and  areas  to  be  used  by  one  or  more  application 

1 programs . 

Data  Manipulation  Language  (DML)  — A facility  for  accessing  base.  It 
provides  a wide  range  of  comnands  for  requesting  database  services  which 

* 

store  data  in  the  database  or  returns  data  to  the  user's  program. 

Schema  Description  for  SIDPERS 

• u 

TV  T PERS  test  database  was  designed  to  support  the  six 
trans^.-  ypes  identified  earlier.  The  overall  system  architecture 
reflects  „welve  record  types  organized  into  four  IDMS  areas.  These 
areas  reflect  functional  differences  in  the  data  that  is  stored  and 
its  use.  PERSONNEL  area  contains  the  individual  solder  and  unit  records 

l! 

of  an  installation.  The  MSCAREA  contains  diagnostic  and  error  messages. 

The  ADAREAL  and  ADAREA2  Areas  contain  additional  personnel  data.  The  j 

overall  structure  is  shown  in  Figure  A 2.3-2. 

The  record  types  belonging  to  each  of  the  areas  are  identified  in 
Table  A2.3-1.  The  record  occurrence  and  record  size  attributes  of  each 
of  the  record  types  are  also  identified  in  this  table.  The  personnel 
, area  is  of  primary  interest  since  most  of  the  SIDPERS  transaction 

activity  references  it  record  types  and  sets.  This  area  consists  of 
.'  f 3,909  records  distributed  among  7 record  types.  Although  the  GRADE 

records  account  for  68%  of  the  total,  the  IDENT  records  (6,2%  of  the 


Figure  A2.3-2  SIDPERS  Data  Diagram 


Table  A2.3-1  Record  Occurrence  Characteristics 


Record  Occurrence 

Record  Type 

Within  Area 

Number 

% of  Total 
(within  area) 

PERSONNEL  AREA 

' ■ *•  ■ v 1J  % 

INST 

1 

0.0 

UNIT -MSTR 

83 

2.1 

I DENT 

203 

5.2 

UIST 

468 

12.0 

GRADE 

2,656 

68.0 

POSNO 

403 

10.3 

MOSE 

95 

2.4 

ADAREAL  AREA 

j 

ADD-IDENT 

200 

70,2 

ADD-UNIT 

85 

29.8 

MSGAREA  AREA 

COMPATIBLE 

155 

62.0 

VALIDITY 

95 

38.0 

| 

ADAREA2  AREA 

AALOC 

_ 

95 

100.0 

Record  Size 


.01 
.79 
4.12 
6.82 
11  .78 
9.45 
3.67 


23.13 

18.85 


14.93 

15.65 


Includes  IDMS  Overhead  of  8 bytes  per  record 


- 72 


total)  are  mosc  frequently  accessed.  Most  of  the  transactions  are 
oriented  toward  updating  an  individual  soldier's  data  and  thus  the  most 
common  entry  point  is  the  IDENT  record.  This  is  accessed  via  the 
CALC  set  using  the  soldier's  last  name. 

Figure  A2.3-2  identified  the  organization  of  the  personnel  area 
record  types  into  sets.  Ten  distinct  set  types  (excluding  the  CALC 
sets)  are  employed  to  provide  the  inter -record  traversal  capabilities 
required  by  the  SIDPERS  transactions.  Table  A2.3-2  identifies  these 
sets  and  displays  their  characteristics.  The  sets  are  identified  by 
both  an  "external"  name  which  is  the  set  name  used  in  the  SIDPERS 
subset,  and  also  by  an  "internal"  name  which  is  the  set  identifier 
within  the  IPSS  models.  For  modeling  purposes,  two  data  items  per  set 
type  were  derived  from  analysis  of  the  sample  data  base.  These  were: 

1.  the  probability  of  an  owner  record  type  having  a non-null  set  of 
member  records  associated  with  it  (i.e.,  the  probability  of  a set 
occurrence) , and 

2.  the  number  of  member  records  in  a set  occurrence  for  each  set  type. 
Table  A2.3-2  also  identifies  these  data  items  for  each  set  of  the 
PERSONNEL  AREA.  Although  the  table  shows  the  average  number  of  member 
records,  for  modeling  purposes  probability  distribution  functions  were 
used  to  more  accurately  characterize  the  database. 

The  records  of  the  SIDPERS  data  base  reside  within  specially  formatted 
IDMS  pages.  These  IDMS  pages  are  virtual  pages  since  they  represent  the 
data  as  known  by  IDMS  and  as  such  need  not  be  reflective  of  secondary 
storage  record  organization.  The  page  size  itself  is  a function  of  the 
IDMS  processing  environment.  Interactive  SIDPERS  with  IDMS  operating  on 
IBM  370/165  equipment  uses  a page  size  of  3,156  bytes,  whereas  the  page 
size  for  IDMS  operating  on  a PDP-11/70  is  projected  to  be  1,024  bytes. 

The  test  version  of  the  SIDPERS  data  base  has  been  loaded  onto  IDMS 
pages  as  shown  in  Table  A2,3-2,  The  Personnel  Area  occupies  200  pages 
and  is  36.6°:  full.  The  IPSS  simulation  model  of  this  data  base  assumes 
• PDP-11/70  environment  as  the  number  of  pages  and  page  range  was  adjusted 
>*ep  the  percent  utilization  the  same  while  changing  the  page  size  to 
: ',/tes.  This  data  is  also  reflected  in  Table  A2.3-3, 
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Set  Name 

Record  Type 
Participation 

Probability 
of  Set 

External  ID 

Internal 

Owner 

Member 

Occurrence 
Given  Owner 
Record 

INST-UNIT-MSTR 

INUM 

INST 

UNMA 

1.0 

UNIT-MSTR-POSNO 

UMPOS 

UNMA 

POSN 

•9 

UNIT-MSTR-UIST 

UMUI 

UNMA 

UIST 

1.0 

UNIT-MSTR-AWOL 

UMAW 

UNMA 

UIST 

0.0 

UNIT-MSTR-GRADE 

UMGR 

UNMA 

GRADE 

1.0 

POSNO-UIST 

POUI 

POSN 

UIST 

0.0 

GRADE-UIST 

GRUI 

GRADE 

UIST 

.94 

IDENT-UIST 

I DU  I 

IDEN 

UIST 

1.0 

MOSC-PMOS 

PMID 

MOSC 

IDEN 

.86 

MOSC-SMOS 

SMID 

MOSC 

IDEN 

.57 

Average 
Number  of 


Member 

Records 
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Table  A2.3-3  Page  Utilization  Within  the  SIDpERS  Areas 


Area 

Page  Size  = 3 ,1 56  Bytes 

Page  Size 

= 1 ,024  Bytes  | 

Number  of 
Pages 

Page 

Range 

Utilized 

Number  of 
Pages 

Page 

Range 

Personnel 

200 

1-200 

36.64 

617 

1-617 

ADAREA1 

80 

201 -280 

41  .98 

246 

618-863  ! 

MSGA2EA 

100 

301 -400 

30.58 

308 

925-1233  j 

1 

ADAREA2 

20 

281 -300 

.15 

60 

864-924 

i 

DML  Description  for  SIDPERS 

A previous  study  of  a VIABLE  transaction  has  specified  the  number 
and  type  of  IDMS  DMLs  that  are  issued  as  well  as  their  sequence  within 
the  transaction  (SHA77 ) . These  DML  have  been  classified  by  type  as 
shown  in  Table  A2.3-4. 

The  function  of  each  of  these  DML  Commands  is  as  follows: 

FIND:  Locates  the  selected  record  in  the  data  base  and  returns  its 
identity  to  the  application  program. 

OBTAIN:  Locates  the  selected  -ecord  in  the  data  base  and  returns 
the  record  as  well  as  its  identity  to  the  application  program. 

MODIFY:  Causes  the  specified  record  to  be  updated. 

STORE : Causes  the  specified  record  to  be  stored  in  the  data  base. 
ERASE : Causes  the  specified  record  to  be  physically  removed  from 
the  data  base, 

CONNECT : Causes  the  specified  record  to  be  inserted  into  an 
identified  set. 

DISCONNECT : Causes  the  specified  record  to  he  removed  from  the 
identified  set. 


Table  A2.3-4  SIDPERS  IDMS  DML  Types 


Category 

' M ~~  ' ” ~ ~ 

FIND/ OBTAIN 

FIND  record -name  RECORD 

FIND  NEXT  record-name  RECORD  of 
set-name  SET 

FIND  OWNER  RECORD  OF  set -name  SET 

OBTAIN  record-name  RECORD 

OBTAIN  NEXT  record -name  RECORD  of 
set-name  SET 

OBTAIN  OWNER  RECORD  OF  set -name  SET 

MODIFY/STORE/ERASE 

MODIFY  record-name  RECORD 

STORE  record -name  RECORD 

ERASE  record -name 

CONNECT/DISCONNECT 

COWIECT  record-name  TO  set-name 

DISCONNECT  record-name  FROM  set -name 

Within  the  IPSS  model  of  VIABLE  SJDPERS,  each  IDMS  DML  is  represented  by 
statements  which  invoke  a lower  level  service  and  wait  for  its  completion. 
Four  parameters  that  are  required  to  pass  the  DML  information.  These 
are: 

1.  DML  Type  (FIND,  OBTAIN,  etc.); 

2.  Qualifier  (NEXT,  OWNER,  etc,); 

3.  Record  Type  Identified  (ADDI , IDEN,  etc.);  and 

4.  Set  Type  Identifier  (GALC,  GRUI,  etc.). 


A3.  MODELING  USING  THE  IPSS  DESIGN  FACILITY 


A3 .1  A Functional  View  of  the  Modeling  Design 

The  purpose  of  the  host  and  the  backend  submodels  is  to  provide 
specific  computer  system  environments  for  the  SIDPERS  application  and  IDMS 
submodels.  The  relationship  between  these  submodels  can  be  seen  in 
Figure  A3. 1-1.  The  SIDPERS  submodel  was  constructed  by  characterizi ng 
the  functional  SIDPERS  processes  required  by  a SIDPERS  transaction  from 
the  time  it  enters  the  host  system  until  the  completion  of  processing. 

These  functional  processes  included  such  activities  as  input  validation, 
backend  interaction,  and  diagnostics  transmissions.  The  SIDPERS  submodel 
characterized  these  processes,  however,  in  a computer  system  free  environ- 
ment, concerning  itself  only  with  the  impact  of  these  various  processes 
on  SIDPERS  processing.  Similarily,  the  IDMS  submodel  was  constructed 
with  no  assumed  computer  system  environment.  Functions  such  as  buffer 
and  page  management,  DML  invocation  and  host  interfacing  were  characterized 
as  part  of  the  IDMS  submodel,  at  the  level  of  complexity  of  the  IDMS 
request.  Both  the  host  and  backend  computing  environments  were  treated 
as  black  boxes  in  these  models.  Thus,  the  initial  preliminary  model  had 
the  SIDPERS  submodel  interacting  with  the  IDMS  submodels  (arrows  A & B). 

The  purpose  of  the  host  and  backend  submodels  were  to  provide  a 
specific  computer  environment,  including  hardware,  software  and  data 
elements,  within  which  the  SIDPERS  and  IDMS  submodels  could  operate.  The 
operating  system  functions  that  had  been  assumed  to  be  operational  in 
the  application  oriented  submodels,  but  had  been  aggregated,  were  now 
characterized.  For  example,  transmitting  SIDPERS  diagnostic  messages 
to  the  user  at  the  terminal  involves  accessing  the  message  from  the 
host's  disks  (including  I/O  scheduling,  disk  allocation  and  I/O  operations) 
and  the  actual  transmission  (which  requires  TP  scheduling,  TP  line 
allocation  and  I/O  operations).  With  respect  to  the  IDMS  submodel,  the 
function  of  page  replacement,  for  example,  involves  task  scheduling, 
resource  allocation,  and  memory  management.  It  is  the  characterization 
of  these  support  functions  that  the  host  and  backend  submodels  provided. 
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The  processing  relationship  of  these  submodels  is  also  demonstrated 
in  Figure  A2.1-1.  A SIDPERS  transaction  enters  the  system  through  the 
SIDPERS  application  submodel  (1)  and  continues  to  operate  in  this  submodel 
until  it  requires  a host  operating  system  function.  At  that  time  it 
triggers  off  a host  function  to  perform  the  needed  operating  system 
function,  such  as  task,  job  or  resource  management  (2).  both  submodels 
continue  processing  other  transactions  and  events  that  may  be  occurring 
simultaneously.  In  essence,  then,  the  host  submodel  operates  in  parallel 
with  the  SIDPERS  model,  satisfying  its  operating  system  needs  and 
coordinating  the  execution  of  concurrent  SIDPERS  processes.  The  host 
submodel  is  essentially  in  a reactive  mode,  residing  in  a continual  wait 
state  until  awakened  by  the  SIDPERS  application  submodel  requesting  a 
host  service.  Communication  between  the  host  is  accomplished  between 
the  host  and  backend  submodel  (3).  The  backend  submodel  then  initiates 
the  appropriate  IDMS  service  to  satisfy  the  DML  request  sent  from  the 
host  (4).  From  then  on,  however,  the  backend  and  IDMS  submodels  operate 
in  a parallel  as  does  the  host  and  SIDPERS  submodels. 

Previous  studies  of  the  V IABLE/S IDPERS  project  have  not  designated  a 
particular  type  of  computer  system  as  the  host  machine.  Thus,  the  model 
that  was  developed  has  been  designed  to  be  a general  host  machine  model, 
including  those  operating  system  functions  that  would  be  necessary  on  any 
machine  that  as  host.  The  structure  of  the  host  model,  however,  is  such 
that  the  particular  software  and  hardware  of  any  computer  system  can  be 
substituted  for  those  in  the  initial  model  without  modification  of  the 
existing  SIDPERS  application  submodel  and  little  modification  of  the 
host  submodel.  Currently,  the  test  bed  SIDPERS/IDilS  system  resides  on 
an  IBM  370/165,  both  the  host  and  the  backend.  Thus,  although  the 
structure  of  the  host  submodel  in  this  project  is  general,  the  particular 
elements  are  specific  to  the  USACSC  HCC  IBM  370/165.  The  backend 
machine,  however,  has  been  chosen  to  be  a PDP-11/70  and  the  resultant 
backend  model  will  reflect  the  operating  system  philosophies  of  this 
sys  tern . 

In  modeling  these  two  types  of  environments,  a similar  approach  was 
taken.  It  is  assumed  in  the  IPSS  methodology  that  operating  systems. 


in  general,  perform  certain  types  of  seryices  regardless  of  the  particular 
machine.  As  Figure  A3. 1-2  illustrates,  although  an  operating  system  may 
be  servicing  many  different  applications  simultaneously,  the  coordinating 
and  servicing  of  these  applications  is  completed  through  a stage  set  of 
underlying  operating  system  functions.  The  types  of  system  functions 
performed  are  job  scheduling,  task  management,  resource  allocation,  I/O 
supervision  and  telecommunication  control.  Thus,  both  the  host  and  the 
backend  submodels  were  constructed  by  characterizing  these  functions  in 
general  and  then  particularizing  them  to  the  specific  machine,  IBM  370/165 
and  PDP-11/70.  The  structure  of  these  submodels,  however,  is  such  that 
at  any  later  time  the  hardware  and/or  software  can  be  changed  to 
represent  another  system. 

It  should  be  emphasized  that  these  characterizations  of  the  computer 
systems  were  not  dependent  on  the  applications  to  be  run  on  them,  i.e., 
SIDPERS  and  IDMS.  A future  application  of  these  submodels  is  to  change 
the  loading  on  the  computer  submodels  to  include  other,  possible  other 
SIDPERS,  applications  to  determine  the  effect  on  SIDPER/IDMS  processing. 
Thus,  the  scheduling  and  allocation  policies  that  are  coded  for  these 
submodels  do  not  reflect  the  particulars  of  either  SIDPER  or  IDMS  and 
are,  essentially,  general  task  and  resource  managers. 

A3. 2 IPSS  Model  of  Host  Computer 

The  approach  taken  in  using  IPSS  to  model  this  computer  system  is 
to  first  model  the  static  elements  of  the  system,  the  hardware  and  the 
data  and  then  model  the  dynamic  software  elements.  The  host  computer 
that  was  modeled  was  the  USACSC  HCC  IBM  370/165.  To  construct  the  hard- 
ware configuration  of  this  machine,  only  those  elements  that  were  impacted 
by  the  SIDPERS  application  were  modeled.  Specifically,  they  were  the 
secondary  storage  devices  upon  which  the  IDMS  error  message  files  were 
kept,  the  backend  interfacing  equipment,  external  terminals  through 
which  USACSC  personnel  invoke  and  interact  with  SIDPERS,  and  the  connect- 
ing telecoimunication  equipment.  Other  hardware  typical  of  an  IBM 
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370/165  were  not  included  as  they  would  not  be  referenced  in  this  model, 
but  at  a later  point  in  time  when  other  USACSC  applications  are  added  to 
the  host  model,  additional  hardware  can  be  easily  added. 

Figure  A3, 2-1  illustrates  the  initial  hardware  configuration  that 
was  assumed  for  the  host,  IBM  370/165  computer.  The  particular  secondary 
storage  devices  assumed  were  a bank  of  eight  IBM  3330  DASDs , their 
associated  control  units,  and  single  channel,  A single  CPU  with  2 
megabytes  of  main  memory  were  assumed  to  characterize  the  host  computer. 
The  external  terminals  were  assumed  to  be  similar  to  IBM  2741  and  the 
communication  line  between  the  host  computer  and  these  terminals  was 
assumed  to  be  a 2400  baud  line.  It  should  be  noted  that  in  an  IPSS  model 
the  characteristics  of  anyone  of  these  hardware  devices  can  be  modified 
without  requiring  the  modification  of  the  rest  of  the  model  . Thus, 
experiments  evaluating  different  combinations  of  devices  can  be  easily 
made. 

The  second  step  in  constructing  an  IPSS  model  is  to  define  the 
secondary  storage  data  files.  With  respect  to  the  SIDPERS  application, 
the  only  data  files  associated  with  the  host  computer  are  the  files  of 
validity  and  compatibility  error  messages.  The  validity  error  file  is 
accessed  once  for  a compatabil ity  error  by  the  SIDPERS  application 
software.  Although  there  was  little  data  on  the  size  and  internal 
characteristics  of  these  files  the  following  was  assumed:  logical 
record  length  of  80  bytes,  physical  record  length  of  4000,  (to  fit  into 
the  VM  OS  page  size  of  4096),  1000  validity  records,  200  compatibility 
records  and  placement  of  the  two  files  on  the  same  volume. 

The  crucial  aspect  of  this  and  any  IPSS  model  is  the  characterization 
of  software  processing.  It  has  been  mentioned  that  the  operating  systems 
of  both  the  host  and  the  backend  computers  were  assumed  to  be  in  a 
reactive  mode,  responding  to  the  needs  of  their  respective  applications. 
Thus,  in  order  to  determine  the  operating  system  functions  that  needed 
to  be  modeled  in  the  host  (and  backend)  IPSS  submodels,  the  processing 
requirements  of  the  SIDPERS  (and  IDMS)  applications  must  be  examined. 

The  requirements  for  the  host  can  be  seen  by  examining  the  functional 
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steps  that  a SIDPERS  transaction  goes  through  that  were  detailed  in 
Section  A1 . Sunmarizing,  there  were  five  basic  steps  as  shown  in 
Figure  A3. 2-2:  log-on,  SIDPERS  scheduling,  data  input  and  validation, 
IDMS/backend  interaction,  and  log-off.  At  each  of  these  steps  particular 
operating  system  functions  are  required  at  verying  levels  of  complexity. 

To  satisfy  these  needs,  certain  salient  operating  system  functions 
were  identified.  These  were:  the  scheduling  and  transmission  of  data 
to/from  the  user,  the  scheduling  of  a SIDPERS  application  within  the 
host,  the  communication  requirements  of  interactive  data  input  and  the 
necessary  resource  allocation  and  I/O  scheduling  to  access  the  error 
message  files  and  the  scheduling  transmission  and  repetition  of  messages 
to/from  the  backend  computer.  Underlying  all  these  processes  is  the 
synchronization  and  coordination  of  the  SIDPERS  application  functions 
and  the  host  operating  system  functions  which  may  be  executing  in 
parallel,  as  provided  by  general  task  management  and  resource  allocation. 

The  relationship  between  the  IPSS  services  that  characterized  the 
SIDPERS  application  and  the  IPSS  services  that  performed  the  host  functions 
are  shown  in  Figure  A3. 2-3.  Being  that  SIDPERS  is  an  interactive  system, 
constant  communication  between  the  user  and  the  SIDPERS  system,  through 
the  host,  must  be  maintained.  Thus,  each  of  the  five  SIDPERS  application 
steps,  in  some  way,  require  the  scheduling  and  transmission  of  information 
to  or  from  the  user.  In  the  resulting  IPSS  submodel  this  interface  was 
handled  by  the  service  XTCAM,  which  acted  as  scheduler  for  TP  to  the  user. 
It  was  awakened  by  a SIDPERS  module  and  returned  to  the  wait  state.  The 
requesting  SIDPERS  module  was  then  in  control  of  the  use  and  disposition 
of  the  TP  line.  The  second  step  was  to  specifically  scheduled  the 
SIDPERS  application  for  execution  in  the  host  system.  This  was  performed 
by  the  IPSS  service  JOBSCH  which  controlled  the  allocation  of  main  memory 
and  central  processor  and  placed  the  incoming  SIDPERS  application  in 
the  ready  queue.  It  is  general,  though,  so  that  other  non-SIDPERS  jobs 
could  also  be  scheduled. 

The  third  SIDPERS  application  step,  data  input  and  validation,  was 
characterized  in  the  SIDPERS  application  submodel  by  the  services  VALID, 
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VERR  and  CERR,  representing,  respectively,  input  process,  validity  error 
accessing  and  compatibility  error  accessing.  Each  of  these  modules 
involves  communication  with  the  user,  thus,  necessitating  interaction 
with  the  host  service  XCAM.  VERR  and  CERR  also  require  the  access  of 
the  host  disk  storage  subsystem.  This  process  is  regulated  by  a disk 
scheduler  and  device  allocator,  XHDSK.  The  actual  I/O  commands  are 
performed  by  an  IOCS  routine  labeled  DISKA  in  the  IPSS  submodel  of  the 
host. 

The  fourth  step  in  a SIDPERS  application  is  the  l)ML  processing, 
including  the  interface  with  the  backend  computer  for  the  purposes  of 
sending  the  DML  request  to  the  backend,  and  receiving  the  retrieved 
record  from  the  backend  IDMS,  The  SIDPERS  submodel  services  for  each 
transaction  type  and  the  service  INTF  determine  the  particular  DML 
required  for  the  transaction  and  perform  any  pre/post  DML  processing. 

The  actual  interface  to  the  backend  computer  is  performed  by  HINTF. 

This  service  characterizes  the  packaging  of  the  DML  request  for  trans- 
mission to  the  backend,  buffer  management  (BUFALC),  scheduling  of  the  TP 
line  to  the  backend  (HOBETR)  and  allocation  of  that  line.  In  the 
preliminary  submodel  of  the  host,  the  backend  processing  was  black 
boxed  and  service  BACK  characterized  this  implementation.  BACK  also 
controlled  the  deallocation  of  resources  (buffers  and  TP  line).  The 
final  SIDPERS  step  of  log-off  parallels  the  log-on  procedure,  performing 
allocation  (now  deallocation)  of  resources  and  job  scheduling. 

In  order  to  characterize  the  host  operating  systems  functions  as 
they  would  normally  operate,  asynchronously,  the  IPSS  submodels  had  to 
operate  (or  simulate)  asynchronously.  The  interface  between  the  host 
and  the  backend  is  also  an  asynchronous  process.  The  IPSS  built-in 
statements  of  POST/WAIT  EVENT  allow  XTCAM,  XHDSK  and  HOBETR  to  remain 
in  a wait  state  until  needed.  The  IPSS  built-in  statements  FIND  IN  QUEUE, 
WAIT  IN  QUEUE,  and  REMOVE  FROM  QUEUE  allow  these  services  to  maintain  a 
queue  containing  suspended  SIDPERS  transactions  via  any  queueing 
discipline. 


Testing  of  this  host  submodel  was  done  in  conjunction  with  the 
previously  tested  SIDPERS  application  submodel.  Since  the  host  model 
was  always  in  a reactive  mode,  completely  independent  testing  was  not 
appropriate.  Additionally,  the  use  of  this  submodel  was  to  determine 
the  effect  of  host  support  for  SIDPERS  processes  to  that  the  SIDPERS 
application  submodel  was  a necessary  part  of  this  testing, 

A3. 3 IPSS  Model  of  Backend  Computer 

The  backend  computer  was  modeled  by  first  characterizing  the 
great  features  of  that  system,  i.e,,  the  hardware  and  data,  and  then 
modeling  the  dynamic  software  features.  Since  previous  USACSC  studies 
had  indicated  that  the  PDP-11/70  would  be  used  as  the  backend  computer, 
a more  specific  model  than  that  built  for  the  host  could  be  developed. 

The  hardware  configuration  for  the  existing  USACSC  AERMICS  PDP-11/70 
at  Georgia  Institute  of  Technology  was  modeled  as  part  of  the  Systems 
Reserve  Component.  Since  backend  computer  is  to  be  used  for  other 
applications  besides  supporting  the  IDMS  system,  the  complete  configura- 
tion needed  to  be  modified,  not  only  those  elements  directly  affecting 
IDMS. 

Figure  A2.2-1  illustrates  the  Idealized  hardware  configuration  of 
the  USACSC  AIRMICS  PDP-11 /70  system  used  in  the  model  . Although  the 
physical  system  itself  was  unavailable,  sufficient  DEC  documentation 
existed  so  that  detailed  modeling  of  individual  device  characteristics 
could  be  achieved.  Several  hardware  elements  of  this  model  that  have 
significant  impact  on  the  software  processing  and  thus  software  modeling, 
of  this  system  are:  (1)  the  central  UNIBUS  data  and  control  path;  (2) 
the  two  dedicated  high  speed  controllers  to  disk  and  tape  drives;  (3)  the 
use  of  cache  memory  by  the  core  and;  (4)  communication  link  between  host 

and  backend.  It  should  be  noted  that  in  this  and  many  IPSS  models,  the 
characteristics  of  any  one  of  the  hardware  devices  can  be  modified 
without  requiring  the  modification  of  the  rest  of  the  model  . 
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Defining  the  characteristics  of  the  particular  data  sets  that 
reside  on  this  system  is  the  second  modeling  step.  For  this  application, 
only  the  IDMS  test  data  base  was  modeled.  Each  of  the  IDMS  records  was, 
essentially,  a 1024  byte  page  (i.e.,  Physical  record)  with  varying 
highly  logical  records  in  each  page.  The  IDMS  test  data  base  contained 
200  pages  and  the  IDMS  file  organization  was  direct.  Other  data 
sets  for  this  and  other  applications  can  be  easily  added  to  these 
definitions . 

The  characterization  of  the  backend  software  processing  follows 
much  the  same  pattern  as  the  characterization  of  the  host  software. 

Both  operating  systems  are  assumed  to  be  in  reactive  models,  waiting 
for  and  responding  to  the  needs  of  the  resident  applications.  Thus, 
to  determine  the  operating  system  functions  to  be  modeled,  the  processing 
requirements  of  the  IDMS  applications  were  examined.  A DML  request  in 
the  backend  follows  a five  step  process:  request  arrival,  IDMS  scheduling, 
IDMS  processing,  physical  record  retrieval,  and  record  transmission  to 
the  host.  (See  Figure  A3 .3-1).  At  each  of  these  steps  particular 
operating  system  functions  are  required. 

To  satisfy  functional  IDMS  requirements  for  DML  processing,  certain 
PDP-11/70  operating  system  functions  were  identified.  As  Figure  A3. 3-2 
shows,  these  were:  the  scheduling  and  transmission  of  data  to/from 
the  host,  the  scheduling  of  IDMS  within  the  backend,  and  the  necessary 
resource  allocation,  buffer  allocation,  I/O  scheduling  and  I/O  execution 
to  retrieve  the  desired  record.  Underlying  processes  such  as  the 
synchronization  of  IDMS  and  backend  functions,  which  may  be  executing  in 
parallel,  is  provided  for  In  the  model  by  generalized  task  management  and 
resource  allocations  procedures.  Although  CPU  scheduling  was  not  included 
as  part  of  these  functions,  UNIBUS  scheduling  was  an  integral  part  of  the 
synchronization  process. 

The  relationships  between  the  general  DML  processing  step  and  their 
corresponding  IDMS  services,  and  between  these  services  and  those 
characterizing  backend  operating  system  functions  is  depicted  in 
Figure  A3 ,3-2.  Both  the  first  and  the  last  steps  in  DML  processing 
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Figure  A3. 3-2  IPSS  Realization  of  Back-end/ I DfoS  Model 


require  communication  with  the  host  machine.  This  entails  not  only  a 
service  to  characterize  the  backend  interfacing  functions  such  as  the 
message  printing  and  line  protocol,  but  also  a service  to  schedule  the 
intercomputer  communications.  In  the  resulting  IPSS  submodel,  this 
scheduling  function  was  performed  by  the  service,  MUB910,  It  scheduled, 
in  a FIFO  manner,  all  requests  to  use  the  host/backend  communication 
interface,  from  either  the  host  or  backend  direction.  It  was  assumed 
for  this  model  that  only  one  message  could  cross  the  interface  at  a time. 
Once  the  service  HUBE10  scheduled  and  allocated  the  interface,  the 
requesting  service  gained  control  of  the  use  and  disposition  of  the 
interface. 

The  second  step  in  DML  processing  is  the  scheduling  of  IDMS  itself. 
As  mentioned  before,  the  PDP-rll/70  is  not  assumed  to  be  decicated  to  the 
support  of  IDMS,  allowing  the  concurrent  execution  of  other  non-IDMS 
applications.  Thus,  each  invocation  of  IDMS,  via  entering  DML  command, 
must  be  scheduled  and  the  appropriate  IDMS  software  allocated.  In  the 
structure  of  IDMS  its  twin  in  the  host  application  signals  CAMP  (Centra  1 
Access  Monitor  Program)  that  a DML  requires  IDMS,  and  CAMP  then  schedules 
the  invocation  of  IDMS  itself.  Only  one  DML  can  use  the  data  base 
functions  at  a time  to  prevent  concurrent  updatings.  The  IPSS  submodel 
for  IDMS  contained  IPSS  services  corresponding  to  CAMP  and  the  actual 
data  base  manipulation  routines  (DBMS).  The  signaling  to  CAMP  that  a 
DML  request  has  arrived  and  needs  DBMS  is  accomplished  via  the  IPSS 
service  XDBSQ.  The  actual  allocation  and  deallocation  occurs  in  CAMP. 

Once  the  DBMS  module  is  involved,  the  DML  is  processed  in  the  third 
step  via  IDMS  internal  routing.  Each  of  these  routines  has  an  analogue 
IPSS  service  that  accomposes  the  high  level  DML  into  a sequence  of 
primitive  DBMS  commands,  IDMS  individually  changes  these  primitives  to 
requests  to  its  virtual  data  store  for  particular  record(s)  which  leads 
to  step  4, 

The  actual  record  retrieval  in  IDMS  is  a two  step  process.  First, 
the  record  location  is  determined  with  respect  to  an  IDMS  page.  The 
currently  core  resident  pages  are  examined  to  see  if  one  of  them 


contains  the  desired  record.  If  none  do,  then  a new  page  must  be 
accessed.  This  page  management  function  is  accomplished  via  the  IPSS 
service  PAGMR  (page  manager),  If  a page  must  be  accessed,  then  buffer 
space  must  be  allocated  ( BUFACE ) and  the  I/O  request  must  be  scheduled 
(XDSCO).  When  the  I/O  operations  can  be  performed,  the  actual  hardware 
devices  for  the  PDP-11/70  backend  computer  are  referenced  via  the  IPSS 
service  DISKB.  Furthermore,  DISKB  simulates  the  allocation/deal location 
of  resources  and  the  actual  I/O  operations  of  each  and  data  transfer. 
DISKB  also  takes  into  account  the  dedicated  data  lists  between  main 
memory  and  auxiliary  storage. 

In  order  to  characterize  the  backend  operating  system's  functions 
as  they  normally  operate,  i.e.,  asynchronously,  the  IPSS  IDMS  and  PDP- 
11/70  submodel  also  had  to  execute  asynchronously.  The  host/backend 
interface  (through  HUBEI 0)  is  also  asynchronous.  To  accomplish  this 
behavior,  communication  with  operating  system  functions  was  characterized 
via  the  posting  of  common  IPSS  Event  signals  (.semaphores) . The  IPSS 
built-in  statements  of  WAIT  EVENT  cause  the  XBBSQ , HUBE10,  XBXCQ,  XDSKQ 
services  to  remain  in  a wait  state  until  needed.  Conversely,  once 
awakened  by  the  IDMS  services,  these  schedulers  utilize  the  IPSS  built-in 
statements  FIND  IN  QUEUE,  WAIT  IN  QUEUE  and  REMOVE  FROM  QUEUE  to  maintain 
queues  of  suspended  IDMS  DML  requests. 

A3. 4 IDMS  Models 

The  purpose  of  the  model  of  IDMS  was  to  characterize  IDMS  DML 
processing  in  order  to  determine: 

1.  the  IDMS  contribution  to  transaction  response  time, 

2.  the  effect  of  widely  varying  workload  definitions, 

3.  the  effect  of  processing  DMLs  concurrently  (through  multiple 
terminal  loadings),  and 

4.  the  effect  of  data  structure  on  processing  efficiencies. 

Two  models  of  IDMS  were  prepared,  one  employing  the  current  IPSS 

facilities  and  the  other  incorporating  advanced  IPSS  features  for  data 


structure  characterization  and  data  base  access.  These  two  models  are 
similar  in  structure,  they  contain  the  same  services  and  the  calling 
sequences  remains  unchanged.  However,  the  IPSS/BASIC  model  does  not 
make  use  of  the  DML  parameters  passed  from  the  SIDPERS  transaction 
services.  Virtual  page  identification  is  characterized  through  prob- 
ability distribution  functions.  Schema  definition  and  data  access 
currency  are  not  represented.  It  was  found  that  these  important  features 
of  data  base  systems  are  very  difficult  to  model  without  the  special 
simulation  facilities  provided  by  IPSS/DBS. 

The  second  model  of  IDMS  represents  these  features  through  the 
advanced  data  structure  and  data  access  facilities  of  IPSS/DBS.  In 
this  model,  the  DML  parameters  passed  by  the  application  services  are 
used  to  traverse  the  data  base.  The  data  base  structure  is  characterized 
through  the  SCHEMA  facility  and  instances  of  the  data  base  are  created 
through  special  purpose  IPSS/DBS  built-in  functions.  This  results  in  a 
much  more  accurate  determination  of  data  base  processing  activities  in 
general  and  virtual  page  referencing  sequences  in  particular. 

Secondary  Storage  functions  were  initially  characterized  by  waiting  an 
average  elapsed  time  of  36  ms  (the  average  time  for  PDP-11/70  head 
positioning  and  rotational  delay).  The  detailed  model  of  the  PDP-11/70 
was  used  to  calculate  these  times. 

Model  Structure  - Model  I 

The  1PSS  model  of  IDMS  consists  of  services  which  interact  in  much 
the  same  way  that  the  IDMS  itself  executes.  The  overall  structure  of  the 
model  is  shown  in  Figure  A3, 4-1.  The  DML  commands  from  the  application 
services  invoke  the  IDMS  Interface  service  which  in  turn  invokes  the 
CAMP  (Central  Access  Monitor  Program)  and  DBMS  services.  The  DBMS 
service  Invokes  one  of  the  7 DML  services  which  represent  data  access 
and  retrieval.  The  interact  with  the  Page  Manager  service  and  a single 
Schema  Definition  service  in  order  to  generate  secondary  storage 
references  for  the  underlying  file  management  system.  The  following  is 
a description  of  the  function  of  each  of  these  services. 
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IDMS  Interface 

This  service  represents  IDMS  processing  activities  that  occur  for 
every  DML  invocation.  It  is  invoked  by  one  of  the  application  programs 
and  represents  the  following  IDMS  functions; 

1.  validity  checking  and  segmentation, 

2.  error  status  checking, 

3.  performing  any  'before'  procedures, 

4.  testing  error  status  from  the  'before'  procedures, 

5.  testing  the  chanel  indicator 

6.  testing  error  status  on  return  from  performing  the  data  base 
management  system  function, 

7.  executing  any  "on  error  during"  procedures, 

8.  executing  any  'after  error'  procedures,  and 

9.  performing  segmentation. 

However,  no  information  was  available  on  the  frequency  or  nature  of 
these  procedures  within  the  test  VI ABLE/SIDPERS  system.  Thus,  these 
functions  were  merely  identified  and  cocumented  within  this  service 
and  can  thus  be  easily  expanded  once  more  data  becomes  available.  This 
service  invokes  the  CAMP  Service  and  waits  for  its  completion. 

Central  Access  Monitor  Program  (CAMP)  Service 

This  service  represents  the  IDMS  program  of  the  same  name.  Its 
function  is  simply  to  thread  requests  as  the  DBMS  service  can  accommodate 
them  thus  holding  the  invoking  services  in  the  wait  state.  Because  of 
the  single  thread  of  processing  represented  by  a single  user  terminal  , 
the  queueing  of  requests  at  this  level  does  not  occur.  However,  queueing 
is  an  important  performance  factor  for  models  with  more  than  one  terminal 
and/or  concurrently  executing  application  programs. 

Data  Base  Management  System  (DBMS)  Service 

This  service  represents  those  functions  at  the  very  heart  of  IDMS, 

namely  the  materialization  of  an  application  record.  This  invokes  the 
schema  and  subschema  definitions,  data  base  currency,  the  content  of 
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buffers,  and  (usually)  requests  to  the  operating  system  for  one  or 
more  data  base  pages.  Because  of  the  magnitude  and  complexity  of  these 
processes,  they  are  modeled  through  several  IPSS  services.  The  DBMS 
service  establishes  the  environment  (e.g.,  page  size,  buffer  size), 
collects  cache  paping  statistics,  invokes  one  of  the  IPSS  DML  services 
and  waits  for  its  completion, 

DML  Service- 

There  are  7 IDMS  DMLs  represented  in  the  IPSS  model , each  through 
its  own  service  definition.  These  DMLs  are  the  IDMS  functions  identified 
in  Table  A2.3-4.  Each  of  these  services  performs  the  logic  of  the 
DML  by: 

1.  determining  the  virtual  page  number  from  the  record  tape 
and  set  parameters  as  well  as  currency, 

2.  determining  if  the  requested  page  is  already  present  in  the 
IDMS  page  cache,  and 

3.  initiating  a service  to  retrieve  the  record  if  not  present. 

Model  Structure  - Model  II 

The  IPSS/DBS  model  of  IDMS  is  similar  in  structure  to  the  IPSS/ 

BASIC  model  reported  in  the  previous  section.  As  shown  in  Figure 
A3. 4-1,  the  application  DMLs  invoke  the  CAMP  service  which  in  turn 
invokes  the  DBMS  service.  In  this  model,  however,  the  DBMS  service 
has  the  additional  functions  of  creating  an  instance  of  the  schema. 

This  is  accomplished  by  the  CREATE  SCHEMA  built-in  facility  which  copies 
the  Data  Base  Structure  Component  schema  definition  into  an  internal 
work  area.  This  service  then  creates  a set  of  arrays  (called  routes) 
which  represent  schema  access  paths.  These  routes  are  the  basic 
mechanism  for  creating  instances  of  sets,  maintaining  currency,  and 
simulating  the  traversal  of  the  data  base. 


A route  consists  of  a series  of  set  identifiers  which  includes 
the  identification  of  the  owner  and  member  record  types.  A single 
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route  incorporates  those  sets  which  are  traversed  by  a series  of 
application  DMLs . For  example,  the  DML  series  of  locating  an  individual 
soldier's  record  via  the  CALC  set  followed  by  locating  his  data  records 
in  the  UIST  record  type  in  figure  A2.3-2,  would  result  in  a route  con-r 
sisting  of  the  CALC  act,  IDENT-UIST  set,  and  the  IDENT  and  UIST  record 
types.  Instances  of  these  sets  are  created  dynamically  based  on 
parameters  supplied  for  the  schema  facility  in  the  Data  Base  Structure 
component.  In  addition,  statistics  are  automatically  collected  on 
data  base  traversal  activities. 

The  DML  services  in  this  IPSS/DBS  model  simulate  the  traversal  of 
the  data  base  through  such  built-in  facilities  as  FIND  NEXT  (member  in 
set),  and  determine  a record's  virtual  page  address  via  the  GET  DATA 
BASE  PAGE  command.  These  virtual  page  references  become  the  loading 
on  the  file  management  system. 


APPENDIX  B 


SUMMARY  OF  MODEL  STATISTICS 


This  appendix  presents  an  overview  and  explanation  of  statistics 
generated  by  the  execution  of  the  IPSS  models  synthesized  for  the 
experimentation  phase  of  the  research.  All  of  the  defined  models  are 
not  reproduced  here,  however,  the  final  section  of  this  Appendix  contains 
the  IPSS  source  listing  for  the  SIDPERS/IDMS  workload  model. 

Bl.  SIDPERS/IDMS  WORKLOAD  MODEL  STATISTICS 

The  SIDPERS/IDMS  workload  model  consists  of  a collection  of  IPSS 
service  facilities  whose  invocation  sequence  is  hierarchical.  Figure 
Bl- 1 depicts  the  relationships  among  the  services  and  indicates  their 
generic  function.  As  shown  in  the  figure,  transaction  arrival  at  a 
work  station  is  represented  in  the  START  service.  Since  a single 
terminal  is  modeled,  the  service  queues  all  arriving  transactions  until 
the  proceeding  one  has  completed.  Transaction  parameters  are  assigned 
(TRANS)  and  the  data  fields  are  inputted  and  validated  (VALID).  Once 
the  application  programs  is  invoked  (ADDSL,  ARRIV,  DEPTR,  DTYC,  GRCH, 

ING)  which  issues  a DML  by  invoking  the  IDMS  interface  routine  (modeled 
by  INTF)  and  passing  appropriate  parameters.  IDMS  processing  is 
sequenced  by  CAMP  which  then  invokes  DBMS.  The  function  of  the  DBMS 
service  is  to  establish  the  IDMS  processing  environment  and  to  invoke 
a DML  service  (CONECT,  DISCON,  ERASE,  AND,  MODIFY,  OBTAIN,  STORE). 

These  services  identify  an  IDMS  page  and  request  its  presence  in  core 
by  invoking  the  PAGMR  service.  PAGMR  manages  the  IDMS  page  buffer 
using  a modified  least-recently-used  page  replacement  algorithm.  In 
this  model,  data  transfer  from  secondary  storage  is  simulated  by  a 
clock  advance  of  36  ms.  Table  Bl - 1 relates  the  IPSS  services  identified 
in  Figure  Bl - 1 to  the  corresponding  SIDPERS/IDMS  activity. 

Statistics  relative  to  this  modeled  process  are  contained  in  the 
following  pages.  An  elapsed  time  of  two  hours  was  simulated;  all  times 


Table  Bl-1.  Index  to  Modeled  SIDPERS/IDMS  Processes 


Level  SIDPERS/IDMS  Process 

IPSS 

Endogenous 

Exogenous 

Service  Name 

Source 

Code 

1 Page 

1 Arrival  of  transaction  at  a 

work  station 

2 Transaction  input  and  verification 

START 

3 

a.  Transaction  input  by  terminal 
operator 

TRANS 

4 

b.  Transaction  verification  by 
system  software 

3 Application  software  processing 

VALID 

10 

a.  Add  a soldier  to  the  data  base 

ADDSL 

31 

b.  Process  soldier's  arrival  at 
the  installation 

ARRIV 

23 

c.  Process  soldier's  departure 
from  installation 

DEPTR 

27 

d.  Process  change  in  soldier's 
duty  status 

DTYC 

18 

e.  Process  soldier's  grade  change 

CRCH 

13 

f.  Process  inquiry 

INQ 

21 

4 Software  processing  performed  by 

the  IDMS  interface  routine 

INTF 

35 

5 IDMS  Central  Access  Monitor 

Processor  (CAMP) 

CAMP 

37 

6 IDMS  DBMS  processing 

7 IDMS  DML  processing 

DBMS 

39 

a.  CONNECT  DML 

CONECT 

50 

b.  DISCONNECT  DML 

DISCON 

51 

c.  ERASE  DML 

ERASE 

52 

d.  FIND  DML 

FIND 

45 

e.  MODIFY  DML 

MODIFY 

46 

f.  OBTAIN  DML 

OBTAIN 

42 

g.  STORE  DML 

STORE 

47 

8 Page  management,  retrieval 

of  pages  from  auxiliary  storage 

PAGMR 

54 

IPSS  MODEL  - SERVICE  HIERARCHY  SERVICE  FUNCTION 


Figure  Bl-1.  SIDPERS/IDMS  Workload  Model  Service  Invocation  Sequence 
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are  reported  in  milliseconds.  The  first  page  of  model  output  shows 
that  the  exogenous  service  START  was  busy  62.4%  of  the  time  and  was 
invoked  nineteen  times.  The  mean  number  of  transactions  at  the  work 
station  at  any  one  time  was  1.1  (the  maximum  number  was  3)  indicating 
that  a single  terminal  is  sufficient  to  handle  the  processing  load 
anticipated  for  a small  data  base  (203  soldiers). 

The  average  elapsed  time  from  transaction  arrival  at  a work  station 
to  complete  is  5.64  min  (338,430  ms).  An  examination  of  the  transit 
time  statistics  for  the  endogenous  service  facilities  reveals  that  the 
majority  of  this  time  was  spent  in  transaction  input  and  validation 
(TRANS  and  VALID  services).  This  is  due  to  the  relatively  long  data 
input  time  required  and  the  terminal  operator  error  rates  reflected 
through  these  services. 

A significant  drop  in  the  percent  busy  and  the  busy  period  mean 
length  statistics  is  evidenced  for  the  INTF  service.  This  indicates 
that  more  terminals  could  easily  be  supported.  An  appropriate  number 
could  be  determined  by  experimentation  with  the  model  parameters. 

An  examination  of  the  DML  statistics  reveals  a relatively  large 
number  of  executions  of  these  services  and  that  the  average  processing 
time  is  low.  For  example,  there  were  83  invocations  of  the  FIND  DML 
service  and  the  average  processing  time  was  37.3  ms.  Most  of  this  time 
was  consumed  by  the  PAGMR  service  which  all  the  DML's  invoke.  The  PAGMR 
is  required  to  bring  pages  into  core,  and  as  reflected  in  the  cache  page 
fault  statistics,  the  miss  ratio  was  high  (94.7%).  This  indicates  that 
the  data  base  is  not  well  organized  with  respect  to  the  DML  processing. 
As  inspection  of  the  DML's  in  the  application  program  services,  however, 
reveals  that  a majority  of  the  processing  is  random  via  CALC  sets,  and 
hence  there  is  very  little  chance  of  more  optimally  organizing  the  data 
base  given  this  processing  load. 

The  last  page  of  statistics  for  this  model  displays  the  queueing 
of  transactions  for  the  DBMS  and  TRANS  services.  Since  the  DBMS  service 
is  single-threaded  (the  function  of  the  CAMP  service),  no  queueing  to 
it  occurred.  However,  if  CAMP  was  multi -threaded  and  the  DBMS  was  not. 
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no  change  would  be  required  in  the  model  to  collect  DBMS  queueing 
statistics.  The  queueing  statistics  for  the  TRANS  service  shows  that 
the  queue  was  never  very  long  (maximum  of  2,  mean  length  of  .6)  again 
indicating  a larger  data  base  or  heavier  transaction  rate  could  easily 
be  accommodated. 
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B2.  HOST/SIDPERS  SUBMODEL  STATISTICS 


Previous  USACSC  studies  did  not  identify  a particular  machine  to 
be  used  for  the  host  environment,  so  a generalized  host  was  modeled. 

To  do  this,  the  software  functions  of  the  host  were  emphasized  more 
than  the  hardware  functions.  Thus,  only  a minimum  hardware  configura- 
tion was  described  and  more  attention  was  paid  towards  determining  and 
modeling  the  host  operating  system  requirements  of  the  SIDPERS 
application. 

The  host  operating  system  was  assumed  to  execute  in  a reactive 
manner,  responding  to  the  needs  of  the  SIDPERS  application.  The 
particular  steps  in  the  modeled  SIDPERS  application  were  discussed 
in  the  main  body  of  this  report  and  in  Appendix  A.  The  needs  of  this 
application  were,  in  general,  task  management  and  resource  allocation.  A 
crucial  host/SIDPERS  interface  was  the  synchronization  of  the  execution 
of  SIDPERS  services  and  operating  system  services.  The  asynchronous 
nature  of  their  execution  compounded  the  problem.  To  model  this  situa- 
tion, IPSS  services  representing  task  schedulers  communicated  with 
existing  SIDPERS  IPSS  services  via  the  posting  of  and  waiting  for  global 
events.  These  events  corresponded  to  a request  for  scheduling  and  the 
completion  of  that  scheduling  process. 

Four  schedulers  were  identified  for  the  modeling  of  the  host/SIDPERS 
interface.  These  controlled  access  to  the  host's  disk  subsystem,  the 
use  of  the  teleprocessing(TP)  line  to  the  user,  the  use  of  the  telepro- 
cessing line  to  the  back-end  and  the  resumption  of  execution  after  a 
back-end  request  was  completed.  Each  of  these  were  characterized  by  a 
separate  IPSS  service  and  their  use  was  controlled  through  a queue, 
exemplified  by  an  IPSS  chain  facility.  When  a SIDPERS  transaction 
required  scheduling,  it  was  placed  in  one  of  these  chains.  The  four 
chains  were  HDSKQ  (disk  subsystem),  TCAMQ  (user  TP  communication), 

HOBEQ  (back-end  TP  communication)  and  RSPONS  (back-end  request  completion). 


- Ill 


The  use  of  these  chains  was  measured  in  IPSS  via  the  queueing  sta- 
tistics shown.  Because  of  the  particular  SIDPERS  workload,  no  SIDPERS 
applications  overlapped,  and,  therefore,  there  was  no  queue  in  transit 
time  associated  with  any  scheduler.  This  condition  also  limited 
the  possibility  of  having  more  than  one  SIDPERS  transaction  enqueued 
simultaneously.  If  such  a situation  occurred  in  the  future,  the 
concurrency  statistics  would  demonstrate  the  degree  of  delay. 

The  queue  entry  statistics  indicate  the  number  of  times  that  the 
current  SIDPERS  workload  requested  each  of  the  scheduling  tasks.  The 
SIDPERS  load  for  the  run  depicted  is  shown  in  the  utilization  statistics 
for  the  IPSS  services  that  characterize  SIDPERS  processing.  The  total 
number  of  SIDPERS  transaction  for  this  run  was  9,  i.e.,  the  number  of 
requests  to  VALID.  The  number  of  requests  to  HDSKQ  corresponds  to  the 
number  of  validity  and/or  compatability  errors  that  occurred  during  the 
current  run,  since  each  error  required  a sisk  access.  Thus,  on  the 
average,  each  incoming  transaction  had  one  error. 

Statistics  measuring  the  communication  with  the  user  and  the 
back-end  indicate  the  complexity  of  the  SIDPERS  application  transac- 
tions. The  number  of  user  interactions  (TCAMQ)  reflects  the  amount  of 
input  required  for  the  current  set  of  SIDPERS  transactions.  Thus, 
for  9 transactions,  a mean  of  5.1  interactions  were  required  per  trans- 
action. This  included  input  of  data  and  output  of  error  messages  and 
records.  The  number  of  entries  in  the  RSPONS  queue  indicates  that  the 
current  input  stream  of  SIDPERS  transactions  generated  145  DML  request 
to  the  back-end.  This  implies  a mean  of  16.1  DML  requests  per  SIDPERS 
transaction  types  and  does  not  take  into  account  the  DML  requirements 
of  particular  transaction  types.  And  finally,  the  number  of  entries 
in  the  back-end  interface  chain,  HOBEQ,  is  twice  the  number  of  the  actual 
DML  requests  since  the  TP  interface  must  be  acquired  for  both  sending 
and  receiving  DML  requests. 
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B3.  IDMS /BACK- END  SUBMODEL  STATISTICS 


The  emphasis  of  this  model  was  on  interfacing  the  IDMS  functions 
with  the  PDP-11 /70  backend  operations.  Because  of  the  wealth  of  docu- 
mentation available  on  the  hardware  aspects  of  the  USACSC  PDP-11/70  (and 
the  lack  of  software  documentation),  the  impact  of  IDMS  on  hardware 
utilization  was  examined.  The  complete  configuration  of  the  USACSC 
PDP-11/70  installation  at  the  Georgia  Institute  of  Technology  was  modeled 
and  is  shown  in  Figure  B3-1. 

The  PDP-11/70  operating  system  employs  a dedicated  data  path 
between  central  memory  and  high  speed  disks  (RWP04AA  in  Figure  B3-1). 

The  IL)MS  data  base  resides  on  these  disks,  allowing  for  rapid  retrieval 
of  IDMS  pages.  DML  requests  entering  the  backend  from  the  host  were 
eventually  mapped  to  specific  data  accesses  to  the  RWP04AA.  Thus,  to 
measure  the  direct  effect  of  the  IDMS  loading  on  the  PDP-11/70  backend, 
the  IPSS  statistics  on  the  behavior  of  this  disk  subsystem  (labeled  RP04AA 
in  the  corresponding  IPSS  model)  are  examined  and  are  found  immediately 
following  this  discussion. 

Utilization  statistics  on  the  RP04AA  provide  the  best  insight 
into  its  performance  relative  to  the  IDMS  loading.  Busy/idle  statistics 
indicate  the  percentage  of  time  that  this  facility  was  utilized.  As 
can  be  seen,  the  RP04AA  was  used  only  23.1%  of  the  time,  remaining  idle 
for  76.9%.  Such  an  imbalance  can  be  attributed  to  the  characteristics 
of  the  device  exceeding  the  needs  of  the  application  or  the  actual 
placement  of  data  on  the  disks. 

Concurrency  statistics  measure  the  degree  of  multiprocessing  that 
occurred  on  the  RP04AA.  In  this  case,  in  order  to  maintain  the  integrity 
of  the  IDMS  data  base,  only  one  access  at  a time  was  permitted.  This 
is  evidenced  by  the  value  of  the  maximum  level  of  concurrency  being  1. 

The  value  of  the  current  levels  equalling  1 implies  that  at  the  end  of 
the  current  simulation  run,  the  RP04AA  device  was  in  use. 

The  last  two  sets  of  utilization  statistics  characterize  the  behavior 
of  individual  accesses  to  the  RP04AA.  Each  access  involves  a seek  and 
a data  transfer  operation.  The  RP04AA  was  acquired  (seized)  through- 
out both  operations.  The  total  number  of  references (19)  and  the  number 


of  zero  time  references  (0)  indicate  the  relative  closeness  of  successive 
page  references  to  the  IDMS  data  base.  A low  percentage,  as  is  the  case 
here,  indicate  that  the  data  may  be  well  spread  out  on  the  disk  or  that 
the  individual  accesses  are  randomly  distributed.  On  the  other  hand,  a 
high  percentage  of  zero  time  seizures  may  indicate  the  compactness  of  the 
data  or  a deliberate  ordering  of  accesses  (e.g.,  sequential  of  within 
an  IDMS  set).  The  mean  total  time  for  an  individual  accesses  to  the 
RP04AA,  23.2  milliseconds,  includes  the  seek  and  data  transfer  operations. 
An  additional  mean  is  calculated  removing  the  bias  of  the  zero  time 
seizures  so  that  an  average  time  per  actual  access  can  be  determined. 

For  each  mean,  the  variability  of  that  mean,  i.e.,  the  standard  deviation, 
is  also  calculated  to  give  some  insight  into  the  relative  accuracy  of 
the  above  means. 

The  impact  of  the  IDMS  functions  can  also  be  shown  in  other  IPSS 
statistics.  The  IDMS  DML  requests  are  mapped  into  I/O  requests  for  which 
IPSS  has  built-in  primitives  such  as  Seek  and  Data  Transfer.  Statistics 
are  automatically  calculated  by  IPSS  on  invocations  of  each  of  these  I/O 
operations  by  each  I/O  operation  (Part  Bl),  by  access  mechanism  (Part  B2) 
and  by  data  set  (Part  B3).  The  statistics  by  the  access  mechanism, 

RP04AA,  aid  in  analyzing  the  impact  of  IDMS  on  the  backend.  The  sum  of 
the  mean  routine  times  for  the  two  I/O  operations  that  referenced 
RP04AA  equals  23.2  milliseconds,  the  same  utilization  time  for  RP04AA 
in  the  previous  discussion.  This  allows  us  to  break  down  the  aggregate 
access  time  to  RP04AA  into  its  component  activities.  It  is  evident 
that  the  Seek  operation  comprises  the  greatest  amount  of  time  in  each 
DML  request  processing.  Thus,  in  order  to  reduce  this  time  factor 
affecting  the  Seek  operation,  such  as  placement  of  data  files, 
compactness  or  device  type,  should  be  examined. 
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B4.  IPSS  FUNCTIONAL  MODEL  OF  THE  SIDPERS/IDMS 

The  purpose  of  this  section  is  to  illustrate  the  use  of  the  IPSS 
to  describe  a complex  information  processing  system  at  the  functional 
level.  This  model  does  not  contain  characterizations  for  the  computer 
hardware,  executive  software,  data  base  management  system  software  or 
data  base.  At  this  level  they  were  treated  as  black  boxes,  however 
appropriate  interfaces  were  defined  so  that  respective  characterizations 
could  be  included  in  later  models. 

The  focus  of  this  model  was  to  model  the  processes  (represented  as 
IPSS  endogenous  services)  encountered  in  updating  the  SIDPERS  data  base. 
Figure  Bl-1  identified  the  hierachical  relationship  assumed  for  the 
model;  Table  Bl-1  related  the  IPSS  service  identified  in  Figure  Bl-1  to  a 
corresponding  SIDPERS/IDMS  data  base  update  procedure.  The  IDMS  data 
base  management  system  backend  was  also  represented  in  the  model. 
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APPENDIX  C 


RESULTS  OF  THE  RESEARCH  ACTIVITIES 

This  appendix  contains  the  conclusions  drawn  from  the  research 
activities.  These  conclusions  are  based  in  a large  part  from  the 
experiences  gained  with  the  IPSS  SIDPERS/IDMS  modeling  activities. 

Recall  that  the  purpose  of  the  modeling  activities  was  to  demonstrate 
the  feasibility  and  suitability  of  the  Information  Processing  System 
Simulator  (IPSS)  with  respect  to  modeling  large  complex  information 
systems.  The  system  modeled  to  demonstrate  these  capabilities  was  a 
host/backend  processor  configuration  which  supported  interactive 
application  processing  and  a data  base  management  system.  The  modeled 
software  processes  included  a detailed  characterization  of  application 
loading,  DBMS  processing,  and  the  operating  system  functions  of  task 
management,  job  scheduling  and  resource  allocation. 

The  research  proposal  identified  164  different  extensions  to  the 
then  existing  IPSS.  As  a result  of  this  research,  139  new  language 
and  statistics  gathering  features  have  been  incorporated  into  the 
IPSS.  Other  extensions  not  in  the  original  proposal  were  also  identified 
as  useful  features  and  are  being  added  to  the  IPSS.  The  results  are 
reported  in  the  following  three  sections  of  this  appendix: 


Section 


Area  Covered 

Data  Base  Systems  - specific  extensions 
Information  System  - related  performance 
statistics 

Computer  Networks  - specific  extensions 


The  vehicle  used  for  assessing  the  usefulness  of  the  suggested  IPSS 
extensions  was  to  model  the  complex  systems  architecture  described  in 
previously  in  this  report.  For  evaluative  purposes,  the  proposed 
extensions  to  the  IPSS  are  each  assigned  one  of  the  following  assessment 
dispositions: 
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Category/Disposition 

. . . NE 
. . . ER 

. . . EU-I 

. . . EU-IM 
. . . EU-D 

. . . EU-DP 

Dispositions  D and  DP  are  Intended  to  show  the  depth  to  which  an  IPSS 
language  statement  under  consideration  has  been  examined.  Paper  models 
demonstrate  effectively  the  definitional  capability  of  IPSS  to  characterize 
information  system  activities  of  Interest,  and  as  such  are  a firm  Indication 
of  the  desire  of  implementing  the  statement  Into  IPSS. 

Cl.  IPSS  LANGUAGE  STATEMENTS  FOR  CHARACTERIZING  DATA  BASE  SYSTEMS 

The  IPSS  system  was  designed  to  analyze  information  processing 
systems  in  their  totality.  To  date,  IPSS  mechanisms  for  the  definition 
and  evaluation  of  hardware,  computer  system  software  and  storage  level 
data  structures  have  been  extensively  developed  and  tested.  The  next 
phase  in  the  continued  development  of  IPSS  was  the  Incorporation  of 
features  for  the  description,  manipulation  and  evaluation  of  logical 
data  structures  of  the  kind  normally  encountered  In  modern  data  base 
systems. 

The  goal  for  this  aspect  of  the  research  was  to  Identify  the 
usefulness  of  incorporating  a set  of  generalized  data  base-related 
characterization  facilities  into  the  IPSS.  Data  Base  Systems  (DBS) 
characterization  is  provided  through  two  components:  one  definitional 
in  nature  which  is  specifically  designed  to  represent  logical  data 
( structures,  and  the  other  procedural  to  represent  application  and  DBS 


( 


Assessment  Conclusion 

Not  Examined  

Examined  and  Rejected  

Examined  and  found  to  be  useful 

- implemented  as  proposed  . . 

- implemented  but  merged  into 

another  facility 

- defined  and  not  implemented 

- defined  and  not  implemented 

but  used  in  paper  model  . 


J 


software  processing.  These  components  have  been  named  the  Data  Base 
Structure  component  and  the  Data  Base  Access  component,  respectively. 
The  relation  of  these  two  components  to  the  existing  model  architecture 
is  shown  in  Figure  Cl -1 . For  purposes  of  identification  they  have  been 
titled  the  IPSS/DBS  submodel  architecture.  The  proposed  language  for 
characterizing  DBS  facilities  for  the  IPSS/DBS  are  identified  in  Table 
Cl-1.  Also  shown  are  the  results  of  their  evaluation  as  part  of  this 
research  effort. 


Cl.l  The  Data  Base  Structure  Component 

The  purpose  of  the  Data  Structure  component  is  to  provide  the 
modeler  with  a set  of  facilities  which  allows  one  to  define  logical 
data  structures  and  to  characterize  the  relationships  among  them. 

This  component  is  defined  independently  of  the  data  base  access  component 
(See  Section  Cl. 2)  and  thus  these  facilities  can  be  applied  to  a variety 
of  DBS  architectures  and  application  environments. 

The  Data  Base  Structure  component  facilities  serve  the  following 
functions: 

1.  They  define  templates  for  schemas  consisting  of  record  types 
and  sets.  Instances  of  which  can  be  transient  entity  definitions 
in  the  DBA  component; 

2.  They  allow  data  base  structures  to  be  viewed  as  a collection  of 
contiguous  logical  areas  and  to  map  these  onto  non-contiguous 
domains  of  a DBS's  storage  structure  and  also  onto  other  logical 
data  structures; 

3.  They  specify  allocation  policies  of  record  type  records  to  the 
sets  in  which  they  participate;  and 

4.  They  allow  the  characterization  of  access  paths  between  record 
types  of  a schema. 

The  Data  Base  Structure  component  permits  the  modeler  to  investigate 
the  effects  on  system  behavior  caused  by  alternate  set,  record  type,  and 
access  path  definitions.  The  definitional  facilities  provided  allow  the 
modeler  to  investigate  a wide  spectrum  of  logical  data  structure  organiza- 
tions and  allocation  policies. 


IPSS  System  Architecture  with  DBMS  Extensions 


Statement 

1 

. . Type  . 

Status  in  IPSS 

Current  Additional 

BUFFER  POOL 

1 Definitional 

I 

! | 
X 

DML  SERVICE 

Executional 

X 

t 

EU-I 

ENDOGENOUS  SERVICE 

1 

! Executional 

[ 

X 

EXOGENOUS  SERVICE 

Executional 

X 

i 

EXTENT 

Definitional 

X 

EU-IM 

REALM 

Definitional 

X 

EU-I 

RECORD  TYPE 

Definitional 

X 

EU-I 

SCHEMA 

Definitional 

X 

EU-I 

SET  TYPE 

Definitional 

X 

EU-I 

★ 

Disposition  codes  are  defined  as  follows: 


EU-I  : Examined,  found  Useful  - Implemented  as  proposed; 

EU-IM:  Examined,  found  Useful  - Implemented  by  Merging 
into  another  facility. 


Schema  Definition 

The  DEFINE  SCHEMA  - END  SCHEMA  statement  sequence  defines  a logical 
data  structure  of  inter-related  elements.  Within  this  sequence  are  the 
definitions  of  sets,  record  types  and  extents. 

Set  Definition 

The  SET  TYPE  statement  characterizes  connections  between  record 
types  in  a schema.  This  statement  identifies  a collection  of  record 
types,  names  the  collection,  specifies  the  type  of  linkage  between  the 
record  types,  identifies  the  type  of  participation  (either  owner  or 
member)  of  the  record  types  in  the  set,  and  characterizes  the  relative 
frequency  of  set  occurrences. 


Record  Type  Definition 

The  RECORD  TYPE  statement  characterizes  those  properties  of  a record 
type  which  are  independent  of  secondary  storage.  The  physical  attributes 
are  expressed  in  terms  of  the  record  format,  the  number  of  record  occur- 
rences, and  record  origin.  An  association  with  an  extent  is  also  provided 
for  linearization.  These  physical  characteristics  are  independent  of 
the  record  location  in  secondary  storage.  (The  IPSS  Storage  Structure 
component  performs  the  required  mappings  from  logical  records  to  storage 
structure  representation.)  This  Data  Base  Structure  component  facility 
completes  the  record  type  definition  of  the  Data  Base  Access  component 
whose  major  purpose  is  to  define  the  source  of  the  records. 


Extent  Definition 

The  EXTENT  statement  defines  one  or  more  extent  facilities.  The 
extent  provides  the  interface  between  a record  type's  logical  address 
space  (defined  via  the  RECORD  TYPE  statement)  and  the  Realm  specification 
defined  via  the  REALM  statement.  Any  number  of  extents  may  be  defined. 
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Realm  Definition 

The  REALM  facility  is  used  to  linearize  the  address  space  of  a 
schema.  The  REALM  statement  provides  the  external  identifier  to  the 
REALM  facility  and  provides  the  space  management  area  associated  with  the 
REALM.  Record  types  may  be  assigned  to  realms  through  the  EXTENT 
statement.  As  many  realms  as  desired  may  be  defined  for  each  schema 
definition.  IPSS  views  a realm  to  be  the  equivalent  of  a virtual  data 
set. 


Cl. 2 The  Data  Base  Access  Component 

The  Data  Base  Access  component  is  the  central  component  in  an  IPSS/ 
DBS  defined  model.  Within  it  are  contained  the  definitions  of  all  the 
required  DBS  and  application  level  software.  Hardware  resources  are 
limited  to  main  memory  buffers  used  by  the  DBS  software  and  user  work 
areas.  All  DBS-related  entity  type  facilities  are  defined  within  this 
component.  This  subsection  describes  those  facility  definition  state- 
ments which  can  appear  within  a Data  Base  Access  component  definition. 
These  represent  extensions  to  the  basic  IPSS  language. 

In  addition  to  the  facilities  identified  below,  the  modeler  can 
include  any  number  of  standard  IPSS  procedure  facilities  and  Fortran 
Subprogram  definitions.  These  defintions  can  appear  anywhere  in  a Data 
Base  Access  component  definition  with  the  exception  that  they  cannot  be 
imbedded  within  any  other  facility  definition.  This  implies  that  a 
Procedure  or  Subprogram  facility  definition  cannot  appear  within: 

1.  Another  Procedure, 

2.  Another  Subprogram, 

3.  An  Endogenous  Service,  or 

4.  An  Exogenous  Service. 

They  may,  however,  be  referenced  from  within  any  of  the  above. 
Procedure  and  Subprogram  syntax  and  semantics  are  discussed  in 
Volume  I of  the  IPSS  Snytax  & Semantics  document  (Section  3.6). 


j 
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DML  Service  Definition 

The  DML  SERVICE  - END  DML  SERVICE  statement  sequence  corresponds  in 
function  to  the  standard  IPSS  Endogenous  Service  definition.  It  has 
been  named  DML  service  in  the  DBA  component  to  more  accurately  reflect 
DBS  service  request  processing. 

Record  Type  Definition 

The  RECORD  TYPE  statement  defines  a record  type  facility  within  the 
Data  Base  Access  Component  and  identifies  the  source  of  the  records 
which  are  created  for  the  specified  record  type  facility. 

Schema  Definition 

The  SCHEMA  statement  identifies  a schema  facility  to  the  Data  Base 
Access  component.  The  named  Schema  is  associated  with  a schema  definition 
in  the  Data  Structure  component  through  EQUATE  statements  in  the  Model 
Stream  Component. 

Cl. 3 IPSS/DBS  Oriented  Built-In  Facilities 

IPSS/DBS  Built-in  Procedure  Facilities  provide  the  modeler  with 
a large  number  of  predefined  capabilities  whose  purpose  Is  to  reduce 
the  time  needed  to  develop  data  base  management  system  models.  These 
procedural  facilities  free  the  modeler  from  the  detailed  mechanics  of 
the  simulation  process.  The  built-in  procedures  have  been  grouped  into 
three  categories  based  on  features  or  functions  cormion  to  each  group 
they  are: 

1.  I/O-oriented  procedures, 

2.  Schema-oriented  procedures,  and 

3.  Data  structure  traversal -oriented  procedures. 

Table  Cl -2  contains  an  alphabetized  listing  of  all  the  IPSS/DBS 
Built-in  procedures  and  denotes  the  dispositions  of  the  statements. 

All  Built-in  procedure  statements  are  converted  to  Fortran  subroutine 
calls  with  the  parmeters  associated  with  that  statement  transposed 
to  subprogram  parameters.  Formal  descriptions  for  these  IPSS  facilities 


Table  Cl -2  IPSS/DBS  Built-in  Procedures 


Statement 

. Type 

Status  in  IPSS 

Disposition 

Current 

Additional 

ACQUIRE  RECORD 

Executional 

X 

EU-DP 

ALLOCATE  SCHEMA  EXTENT 

Executional 

X 

EU-IM 

ALTER  SET 

Executional 

X 

NE 

CONFIGURE  CEQ 

Executlonal 

X 

COPY  SET 

Executional 

X 

NE 

COPY  ROUTE 

Executlonal 

X 

EU-DP 

CREATE  ROUTE 

Executional 

X 

EU-I 

CREATE  SCHEMA 

Executional 

X 

EU-I 

CREATE  SCHEMA  EXTENT 

Executlonal 

X 

EU-IM 

CREATE  TRANSACTION 

Executional 

X 

DESTROY  ROUTE 

Executional 

X 

EU-I 

DESTROY  SCHEMA 

Executional 

X 

EU-I 

DESTROY  SCHEMA  EXTENT 

Executional 

X 

EU-IM 

DISABLE  EVENT 

Executional 

X 

DO  TO  LABEL 

Executional 

X 

ENABLE  EVENT 

Executlonal 

X 

END  DO 

Executional 

X 

FIND  IN  QUEUE 

Executional 

X 

FIND  MEMBER 

Executional 

X 

EU-I 

FIND  NEXT  BUFFER 

Executional 

X 

FIND  ROUTE 

Executional 

X 

EU-DP 

FREE  BUFFER 

Executional 

X 

GET  BUFFER 

Executional 

X 

GET  SAVE  AREAS 

Executional 

X 

IDENTIFY  OWNER 

Executional 

X 

EU-DP 

IDENTIFY  SET  OCCURRENCE 

Executlonal 

X 

EU-DP 

INITIATE  TASK 

Executional 

X 

MERGE  QUES 

Executlonal 

X 

MODIFY  BUFFER  POOL 

Executional 

X 

MODIFY  QUEUE 

Executional 

X 

MODIFY  REALM 

Executlonal 

X 

EU-DP 

MODIFY  ROUTE 

Executional 

X 

EU-DP 

MODIFY  SCHEMA  EXTENT 

Executlonal 

X 

EU-IM 

MODIFY  SCHEMA  RECORD  TYP 

E Executlonal 

X 

EU-DP 

MODIFY  SCHEMA  SET 

Executional 

X 

EU-DP 

PLACE  IN  QUEUE 

Executional 

X 

POST  SEMAPHORE 

Executional 

X 

POST  SIGNAL 

Executional 

X 

PROCESS  TIME 

Executlonal 

X 

PUT  SAVE  AREAS 

Executional 

X 

RELEASE  SCHEMA  EXTENT 

Executional 

X 

EU-IM 

REQUEST  DML  SERVICE 

Executional 

X 

NE 

REQUEST  SERVICE 

Executional 

X 

RESUME  SCAN 

Executional 

X 

SET  FACILITY  STATUS 

Executional 

X 

SET  INDIRECT  REFERENCE 

Executional 

X 

Table  Cl -2  IPSS/DBS  Built-in  Procedures  (Continued) 


Statu 

5-m-iPss 

Statement 

Type 

Current 

Additional 

Disposition 

SET  PRIORITY 

Executiona"! 

X 

SET  SYSTEM  PARAMETER 

Executional 

X 

START  QUEUE  STATISTICS 

Executional 

X 

START  USAGE  STATISTICS 

Executional 

X 

STOP  QUEUE  STATISTICS 

Executional 

X 

STOP  SIMULATION 

Executional 

X 

STOP  USAGE  STATISTICS 

Executional 

X 

STORE  RECORD 

Executional 

X 

NE 

TERMINATE  SERVICE 

Executional 

X 

TERMINATE  TASK 

Executional 

X 

WAIT  DML  SERVICE  COMPLETE 

Executional 

X 

NE 

WAIT  FACILITY  STATUS 

Executional 

X 

WAIT  RECORD 

Executional 

X 

NE 

WAIT  SEMAPHORE 

Executional 

X 

WAIT  SERVICE  COMPLETE 

Executional 

X 

WAIT  SIGNAL 

Executional 

X 

★ 

EU-I  : Examined,  found  Useful  - Implemented  as  proposed 

EU-IM:  Examined,  found 

Useful  - Implemented  by  Merging  into 

another  facility 

EU-DP:  Examined,  found 

Useful  - defined 

and  not  implemented  but 

used 

in  paper  model 

NE  : Not  examined. 

are  not  presented  in  this  report.  IPSS  Syntax  and  Semantics,  Vols.  I 
and  II  presents  the  following  items  of  information  for  each  Built-in 
Procedure: 

1.  Statement  syntax, 

2.  The  function  of  the  statement, 

3.  Semantics  for  the  statement's  parameters, 

4.  A narrative  description  of  the  execution  mechanism, 

5.  IPSS  generated  Fortran  source  code  which  replaces  IPSS 
statements  and 

6.  Examples  of  the  use  of  the  statement. 

Cl. 3.1  IPSS/DBS  I/O  Related  Built-in  Procedures 

The  following  Built-in  Procedures  are  used  to  initiate  I/O  activity 
and  to  wait  for  the  I/O  to  be  completed.  The  ACQUIRE  and  STORE  RECORD 
procedures  determine  the  source  of  the  record  from  the  DBA  component 
record  type  facility  definition.  If  a service  is  specified  as  the 
source,  then  the  service  is  automatically  invoked.  WAIT  RECORD  statements 
are  defined  to  enable  service  processing  to  be  suspended  pending  the  I/O 
operation.  This  section  also  contains  the  definition  of  the  statement  for 
initiating  and  waiting  for  a DML  Service.  These  procedures  can  be  refer- 
enced from  within  either  Procedure  facilities  or  Exogenous  and  Endogenous 
Service  facilities. 

Acquire  and  Store  Record 

The  ACQUIRE  and  STORE  RECORD  Built-in  Procedures  invoke  a service 
which  simulates  the  acquisition  and  storage  of  the  specified  record  to 
and  from  the  service  in  which  the  ACQUIRE  or  STORE  statement  appears. 

The  identity  of  service  to  be  invoked  is  contained  in  the  definition  of 
the  specified  record  type  facility  in  the  DBA  component. 
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Wait  Record 

The  function  of  the  WAIT  RECORD  Built-in  Procedure  is  to  place  the 
specified  transaction  into  the  wait  state  unitl  the  completion  of  the 
Endogenous  service  which  the  specified  transaction  invoked  via  an 
ACQUIRE  or  STORE  RECORD  statement.  Service  for  the  suspended  transaction 
resumes  after  the  specified  wait  criteria  (count  and  request  number)  are 
satisfied.  Each  completed  Endogenous  Service  routine  satisfying  the 
request  number  criterion  decrements  the  suspended  transaction's  Wait 
Count  by  one  and  the  delayed  transaction  is  reactivated  when  the  count 
reaches  zero  and  is  returned  to  the  active  state. 

Request  DML  Service 

The  REQUEST  DML  SERVICE  Built-in  Procedure  is  used  to  initiate  the 
execution  of  a DML  Endogenous  Service. 

Wait  DML  Service  Complete 

The  function  of  the  WAIT  DML  SERVICE  COMPLETE  Built-in  Procedure  is 
to  place  the  named  transaction  into  the  wait  state  until  the  completion 
of  the  specified  Endogenous  DML  Service  which  it  invoked.  Service  for 
suspended  transaction  resumes  after  the  specified  wait  criteria  (count 
and  request  number)  are  satisfied.  Each  completed  Endogenous  DML  Service 
routine  satisfying  the  request  number  criterion  decrements  the  suspended 
transaction's  wait  count  by  one  and  the  delayed  transaction  is  reactivated 
when  the  count  reaches  zero  and  is  returned  to  the  active  state. 

Cl. 3. 2 IPSS/DBS  Schema  Related  Built-in  Procedures 

The  following  Built-in  procedures  are  used  to  change  the  current 
state  of  facilities  defined  in  the  DATA  Structure  component  of  an  IPSS/DBS 
model.  These  procedures  can  be  referenced  from  within  either  Procedure 
facilities  or  Exogenous  and  Endogenous  Service  facilities. 
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Allocate  and  Release  Schema  Extent 

The  effect  of  executing  the  ALLOCATE  SCHEMA  EXTENT  Built-in  Procedure 
is  to  simulate  the  allocation  of  a logical  address  space  to  the  Extent 
subfacility.  The  allocation  causes  the  extent  to  take  on  a displacement 
attribute  which  specifies  an  extent's  displacement  relative  to  a Realm 
facility.  This  is  done  by  placing  the  calculated  displacement  of  the 
extent  start  into  the  Schema  facility's  extent  table.  The  displacement 
is  a real  number  whose  dimension  is  in  terms  of  the  reference  units 
implied  for  the  Realm.  This  information  is  used  by  the  Acquire  and  Store 
Record  Built-in  procedures  (when  the  desired  record  type  has  an  origin 
of  Realm)  to  determine  the  logical  address  of  a record  type  record.  If 
a Schema  Extent  is  not  allocated,  it  is  assumed  to  have  zero  capacity 
relative  to  its  ability  to  hold  schema  records.  The  RELEASE  SCHEMA 
EXTENT  Built-in  Procedure  returns  allocated  address  space. 


Create  and  Destroy  Schema 

The  purpose  of  the  CREATE  SCHEMA  Built-in  Procedure  is  to  create  for 
the  named  Schema  facility  a copy  of  its  associated  Data  Structure  component 
definition.  The  copy  is  placed  in  a pre-specified  area  of  the 
Transaction  Area.  Once  copied,  simulation  functions  involving  the  Schema 
facility  can  occur.  The  definition  remains  valid  until  the  issuing  of  a 
DESTROY  SCHEMA  statement  for  the  same  Schema  facility. 


Create  and  Modify  Schema  Extent 

The  function  of  the  CREATE  AND  MODIFY  SCHEMA  EXTENT  Built-in  Procedure 
is  to  alter  the  current  attributes  associated  with  a Schema  Extent 
facility.  The  attributes  are  first  assigned  via  the  extent  definition  in 
the  Schema  facility  definition  of  the  Data  Structure  component.  A Schema 
Extent  once  created  can  only  be  modified  or  destroyed  and  can  only  be 
"created"  when  it  is  not  in  a "created"  state.  The  procedure  can  only  be 
invoked  after  a Schema  has  been  created. 
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Destroy  Schema  Extent 

The  DESTROY  SCHEMA  EXTENT  Built-in  Procedure  deletes  the  specified 
schema  extent  definition  from  the  named  Schema  facility.  The  destroy 
procedure  releases  the  logical  address  space  associated  with  the  extent 
by  setting  its  size  attribute  to  zero  and  removing  its  Realm  facility 
association. 

Modify  Realm 

The  MODIFY  REALM  Built-in  Procedure  enables  the  modeler  to  change 
the  attributes  associated  with  a Realm  facility  definition.  The  procedure 
changes  only  those  attributes  explicitly  identified  in  the  Modify  Realm 
Statement. 

Modify  Schema  Record  Type 

The  MODIFY  SCHEMA  RECORD  TYPE  Built-in  Procedure  changes  the  parameter 
values  of  the  specified  record  type  facility  definition.  The  original 
parameters  are  specified  in  the  RECORD  TYPE  statements  in  both  the  Data 
Structure  and  DBS  components.  The  procedure  changes  only  those  attributes 
explicitly  identified  in  the  MODIFY  RECORD  TYPE  statement. 

Modify  Schema  Set 

The  function  of  the  MODIFY  SCHEMA  SET  Built-in  Procedure  is  to 
modify  parameters  associated  with  a Schema's  Set  subfacility.  The 
original  parameters  are  specified  via  the  Data  Structure  component's  Set 
facility  definition.  The  procedure  changes  only  those  attributes 
explicitly  identified  in  the  MODIFY  SCHEMA  SET  Statement. 

Cl. 3. 3 IPSS/DBS  Data  Structure  Trversal  Oriented  Built-in  Procedures 

The  following  Built-in  Procedures  are  used  a)  to  create  routes  or 
individual  sets  based  upon  the  schema  definitions  in  the  Data  Structure 
component,  b)  to  modify  routes  or  sets  by  specifying  the  elements  to  be 
changed,  and  c)  to  destroy  an  existing  route.  The  procedure  statements  are 


divided  into  two  groups,  those  which  operate  on  sets,  and  those  which 
operate  on  routes.  These  procedures  can  be  referenced  from  within  either 
Procedure  facilities  or  Endogenous  and  Exogenous  Service  facilities. 

Copy  Set 

The  COPY  SET  Built-in  Procedure  creates  a set  occurrence  from  the 
specified  set  definition.  The  set  occurrence  is  placed  into  an  output 
array  which  the  modeler  designates.  The  set  may  either  be  copied  from 
the  corresponding  set  definition  in  the  Data  Structure  component  or  from 
an  existing  route.  In  either  case  the  modeler  may  change  the  set  traversal 
currency  indicator  during  the  copy  process. 

Alter  Set 

The  ALTER  SET  Built-in  Procedure  modifies  a previously  created  set 
occurrence.  The  specified  set  occurrence  may  either  be  the  output  area 
of  a previously  executed  Copy  Set  procedure  or  may  exist  within  a route. 
This  statement  can  be  used  to  change  the  owner  and  member  record  types  of 
the  set  as  well  as  the  record  occurrences  for  these  record  types. 

Find  Member 

The  FIND  MEMBER  Built-in  Procedure  identifies  a member  record 
occurrence  of  a set  relative  to  the  specified  set  traversal  currency. 

The  output  of  this  procedure  is  an  updated  member  record  occurrence 
and/or  member  record  type  of  the  set's  traversal  currency.  A NO  MEMBER 
EXIT  parameter  is  provided  for  those  cases  in  which  it  is  not  possible  to 
update  this  currency;  for  example,  FIND  NEXT  MEMBER  when  the  number  of 
occurrences  associated  with  the  member  record  type  is  zero.  The  FIND 
MEMBER  examines  the  set  and  the  record  type  facility  definitions  in  the 
Data  Structure  component  in  order  to  determine  the  existence  of  the 
desired  record.  The  statement  types  are  as  follows:  a)  FIND  FIRST 
MEMBER  specifies  that  the  first  member  record  occurrence  for  the 
designated  set  type  is  to  be  located  and  its  identity  placed  in  the  set's 
traversal  currency.  By  "identity"  we  mean  the  member  record  type,  the 


record  occurrence  within  the  set  and  the  record  occurrence  within  the 
record  type.  The  success  of  this  operation  depends  on  a data  structure 
which  directly  links  the  set  traversal  currency  before  execution  of  this 
procedure  to  the  first  record  in  the  set;  b)  FIND  PRIOR  MEMBER  specifies 
that  the  record  to  be  identified  is  the  record  occurrence  which  immediately 
precedes  the  one  specified  by  the  set  traversal  currency.  The  success  of 
this  option  likewise  depends  upon, a direct  link  between  the  record  in  the 
set  traversal  currency  and  the  prior  record  occurrence;  c)  FIND  NEXT 
MEMBER  specifies  that  the  record  to  be  identified  is  the  record  occurrence 
which  immediately  follows  the  record  occurrence  of  the  set  traversal 
currency.  The  successful  completion  of  this  procedure  depends  upon  the 
existence  of  a direct  link  between  the  record  specified  by  the  set 
traversal  currency  and  the  next  record  occurrence  in  the  set;  d)  FIND 
LAST  MEMBER  specifies  that  the  last  record  occurrence  for  the  specified 
set  type  is  to  be  located  and  its  identity  placed  in  the  set's  traversal 
currency.  The  success  of  this  option  depends  upon  a data  structure  which 
directly  links  this  record  to  the  set  traversal  currency  before  execution 
of  this  procedure. 

Identify  Owner 

The  IDENTIFY  OWNER  Built-in  Procedure  identifies  the  record  type 
which  is  the  owner  of  the  specified  record  type  and  identifies  the  set  in 
which  they  both  participate.  This  procedure  examines  the  set  and  record 
type  facility  definitions  in  the  Data  Structure  component  of  the  current 
schema  to  determine  this  relationship.  All  the  sets  which  own  a given 
record  type  can  be  obtained  by  specifying  IDENTIFY  OWNER  followed  by 
successive  IDENTIFY  NEXT  OWNER  statements. 

Identify  Set  Occurrences 

The  IDENTIFY  SET  OCCURRENCE  Built-in  Procedure  identifies  the  sets 
which  the  current  member  record  occurrence  owns.  By  current  member 
record  occurrence  we  mean  the  traversal  currency  as  reflected  in  the 
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specified  set.  This  procedure  examines  the  set  and  record  type  facility 
definitions  in  the  Data  Structure  component  of  the  current  schema  to 
determine  ownership  of  a non-empty  set  of  records.  All  of  the  sets  owned 
by  a record  can  be  obtained  by  specifying  IDENTIFY  SET  OCCURRENCE  followed 
by  successive  IDENTIFY  NEXT  SET  OCCURRENCE  statements. 


Create  Route 

The  CREATE  ROUTE  Built-in  Procedure  determines  the  existence  of  a 
path  between  two  record  types  of  a schema.  The  beginning  and  ending 
nodes  of  the  path  are  specified  in  terms  of  record  type  identifiers.  The 
function  of  this  procedure  is  to  determine  if  these  two  record  types  are 
connected  and  if  the  connections  meet  all  the  set  constraints.  The  set 
declarations  of  the  identified  schema  are  examined  in  the  order  of  their 
declaration  until  either  a path  is  found  or  all  the  declarations  for  the 
schema  have  been  explained.  All  the  paths  between  two  record  types  can 
be  located  by  specifying  PATH  = FIRST  followed  by  successive  PATH  = NEXT 
statements.  When  a path  is  found,  its  sets  are  placed  in  the  $TRANS 
array  beginning  with  the  location  returned  as  the  value  of  the  route 
identifier.  If  no  path  is  found,  the  value  of  the  route  identifier  will 
be  a zero. 

Destroy  Route 

The  DESTROY  ROUTE  Built-in  Procedure  deletes  the  specified  route 
from  the  $TRANS  array.  This  allows  the  re-use  of  the  space  occupied  by 
the  route  for  other  modeling  activities.  The  execution  of  this  procedure 
does  not  affect  schema  definitions  in  the  Data  Structure  component. 


Modify  Route 

The  MODIFY  ROUTE  Built-in  Procedure  changes  the  route  definition  by 
either:  a)  reestablishing  the  current  set,  b)  deleting  or  inserting  sets, 
or  c)  concatenating  another  route  to  the  existing  one.  A route  consists 
of  a sequence  of  set  traversal  tables.  This  procedure  can  change  this 
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sequence  by  deleting,  inserting  or  concatenating  set  traversal  tables 
relative  to  any  of  the  sets  in  the  route.  Only  one  type  of  change  can 
be  specified  for  each  Modify  Route  Statement. 

Copy  Route 

The  COPY  ROUTE  Built-in  Procedure  creates  a route  and  copies  the 
specified  route  data  into  it.  The  sets  in  the  output  route  can  be  modified 
during  this  process.  These  modifications  consist  of:  a)  re-establishing 
the  current  set,  b)  inserting  or  deleting  sets,  or  c)  concatenating 
another  route  to  the  output  route.  These  modifications  can  be  specified 
either  by  naming  specific  sets  or  by  referencing  the  sets  in  the  route 
relative  to  the  set  currency. 

Find  Route 

The  FIND  ROUTE  Built-in  Procedure  uses  a previously  created  route 
and  the  current  schema  definition  to  establish  specific  record  occurrences 
within  the  sets  of  the  route.  A set  other  than  the  first  set  of  the 
route  may  be  designated  as  the  beginning  set  for  the  procedure  to  establish 
record  occurrences.  A set  other  than  the  last  set  in  the  route  may  also 
be  specified. 


C2.  IPSS  PERFORMANCE  MEASURES 

The  proposal  identified  120  extensions  to  the  currently  available 
model  statistics.  The  purpose  of  this  section  of  Appendix  C is  to 
present  the  results  of  the  research  in  the  area  of  added  statistical 
outputs  from  IPSS  models. 

The  Information  Processing  System  Simulator  provides  a modeler  with 
a number  of  statistics  concerning  the  behavior  of  modeler  defined  entities 
and  IPSS  supplied  built-in  services.  These  statistics  fall  into  eight 
general  categories  listed  below.  The  evaluative  results  of  the  research 
is  found  in  Subsections  C2.2  through  C2.8  which  correspond  to  these 
statistics  categories: 
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1.  Operational  Statistics, 

2.  Request  Stream  Statistics, 

3.  I/O  Activity, 

4.  Queueing  Statistics, 

5.  Utilization  Statistics, 

6.  Wait  Statistics, 

7.  Service  Statistics,  and 

8.  Task/Activity  Statistics. 

In  addition  to  these  "automatic"  statistics,  the  modeler  can  employ 
the  complete  facilities  of  the  Fortran  language  to  develop  his  own 
statistics.  Statistics  are  printed  automatically  at  the  conclusion  of 
each  model  simulation  unless  explicitly  inhibited. 

Time  constraints  prohibited  the  implementation  of  any  new  statistics. 
However,  definitions  for  a number  of  the  proposed  statistics  were 
completed  and  are  reported  in  the  appropriate  subsection.  These  statistics 
employ  both  IPSS  facility  specific  variables  and  those  global  to  an  entire 
model.  For  each  defined  statistic  the  variables  required  to  support  their 
collection  and  calculation  are  also  discuss  along  with  the  method  for  data 
collection  including  the  specific  IPSS  statements  responsible  for  the 
activity.  Note:  all  variable  names  used  in  these  definitions  are  for 
publication  purposes  only. 

C2.1  IPSS  Operational  Statistics 

These  statistics  provide  an  overview  of  the  operational  characteristics 
of  the  current  simulation  execution.  The  Clock  and  Termination  Statistics 
involve  the  length  of  the  run,  in  terms  of  both  simulation  time  and  CPU 
time,  and  the  reason  for  termination.  The  Transaction  Statistics  provide 
insight  into  the  degree  of  transaction  activity  generated  by  the  current 
simulation  run.  Statistics  on  the  number  of  transactions  generated  and  the 
average  life  span  of  a transaction  are  collected  by  transaction  type.  The 
results  of  their  evaluation  are  shown  in  Table  C2.1-1.  Table  C2.1-2 
identifies  the  required  data  to  meet  the  definitional  requirements  for 
these  statistical  extentions  to  the  IPSS.  The  explicit  statistic 
definitions  are  shown  in  Table  C2.1-3. 
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Table  C2.1-1  IPSS  Operational  Statistics 


Statistic  Type 

Specific  Statistic 

Currently 

Available 

Proposed 

Extention 

Disposition* 

Clock 

Absolute  elapsed  simu- 

lation  time 

X 

Elapsed  simulation  time 

since  last  reset 

X 

Elapsed  simulation  time 

of  current  model  exe- 

cut ion 

X 

Elapsed  CPU  time  (IPSS 

run  time) 

X 

EU-DP 

Scaling  factor 

X 

EU-DP 

Termination 

Number  of  errors 

X 

Termination  status 

X 

EU-DP 

Transaction 

Total  number  generated 

X 

EU-DP 

(By  Trans- 

Current  number  in  system 

X 

action  type) 

Maximum  number  in  system 

X 

Starting  number  in  syster 

i X 

Total  number  terminated 

X 

EU-DP 

Mean  time  of  existence 

X 

‘Distribution  codes  used  in  this  table  are  defined  as  follows: 


DU-DP:  Examined,  found  useful  - Defined,  not  implemented  but  used  in 

paper  models 


Variable  Name 


Description  of  the  Variable 


Method  of  data  Collection 


I 


VARIABLES  GLOBAL  TO  AN  IPSS  MODEL 


CL0CK1 

Absolute  elapsed  simulation 
time 

Automatically  by  simulation 
driver 

CL0CK2 

Elapsed  simulation  time  since 
last  reset 

Automatically  by  simulation 
driver 

CL0CK3 

Elapsed  simulation  time  of 
current  model  execution 

Automatically  by  simulation 
driver 

CPUTIM 

Beginning  CPU  time  of  current 
IPSS  run 

SVC  call  by  simulation  driver 

Scaling  factor 

Specified  by  user 

1 

Total  number  of  errors  In 
current  model  execution 

Updated  by  internal  IPSS  error 
routine 

TERMST 

Termination  status 

Specified  by  user 

VARIABLES  WHICH  ARE  TRANSACTION  SPECIFIC 

tngena 

Total  number  generated 

Updated  by  simulation  driver 
upon  generation  of  new 
transaction 

tncura 

Current  number  in  system 

Maintained  by  driver  in  SYSINF 

tnmaxa 

Maximum  number  in  system 

Either  user  specified  or  system 
defaul t 

tnstrta 

Starting  number  in  system 

Either  user  specified  or  system 
defaul t 

tntrma 

Total  number  terminated 

Updated  by  driver  upon 
termination 
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Table  C2.1-3  IPSS  Operational  Statistics  - Definition 


Stastic  Type 

Specific  Statistic  Name 

Definition 

Clock 

Absolute  elapsed  simulation 
time 

CL0CK1 

Elapsed  simulation  time  since 
last  reset 

CL0CK2 

Elapsed  simulation  time  of 
current  model  execution 

CL0CK3 

♦Elapsed  CPU  time  (IPSS  run 
time) 

CPUTIM 

♦Scaling  Factor 

SCALEF 

Termination 

Number  of  errors 

ERRM 

♦Termination  Status 

TERMST 

Transaction 

♦Total  number  generated 

tngena 

(by  trans- 
action type) 

Current  number  in  system 

tncura 

Maximum  number  in  system 

tnmaxa 

Starting  number  in  system 

tnstrta 

♦Total  number  terminated 

tntrma 

♦Mean  time  of  existence 

(CL0CK3/TNGENa) 

♦Statistic  currently  exists  in  IPSS  models. 
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C2.2  IPSS  Request  Stream  Statistics 

These  statistics  describe  the  behavioral  characteristics  of  the 
Request  Stream  facilities.  For  each  Exogenous  Event  a profile  of  the 
interarrival  time  mechanism  is  presented.  The  event  of  the  IPSS  built-in 
Endogenous  Services,  ENABLE/DISABLE  Event,  on  the  arrival  of  events  is 
also  summarized.  The  collection  of  these  statistics  is  an  automatic 
by-product  of  the  simulation  drive  mechanism.  Table  C2.2-1  presents  the 
evaluation  results.  Table  C2.2-2  identifies  the  required  model  data  and 
Table  C2.2-3  the  actual  statistic  definition. 


Table  C2.2-1  IPSS  Request  Stream  Statistics 


Statistic  Type 

Specific  Statistic 

Currently 

Available 

Proposed 

Extension 

Disposition* 

— — .... 

General 

Number  generated 

X 

Number  terminated 

X 

EU-DP 

Arrival  Time 

First  generated  arrival 

time 

X 

EU-DP 

Average  interarrival 

time 

X 

EU-DP 

Last  arrival  time 

generated 

X 

EU-DP 

Enable/Disable 

Number  of  enables 

X 

EU-DP 

Total  time  enabled 

X 

EU-DP 

Average  enable  time 

X 

EU-DP 

Number  of  disables 

X 

EU-DP 

Total  Time  Disabled 

x 

EU-DP 

Average  disable  time 

X 

EU-DP 

♦Disposition  Code 

s used  in  this  table  are  defined  as  follows: 

EU-DP:  Examined,  found  useful  - Defined,  not  implemented  but  useful  in 

paper  models 

I 


V I 

#'  v 
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Table  C2.2-2 

IPSS  Request  Stream  Statistics  - Required  Model  Statements 


Variable  Name 

. , — ■ ■ — - ■ — ■ - ■ i 

Description  of  the  Variable 

Method  of  Data  Collection 

EXGEN 

Number  generated 

Updated  by  driver 

EXTRM 

Number  terminated 

Updated  by  driver 

EFARR 

First  generated  arrival 
time 

Specified  by  user  (either 
directly  or  via  Procedure) 

ELARR 

Last  (latest)  arrival 
time  generated 

Updated  by  driver 

ENEN 

Number  of  enables 

Updated  by  ENABLE  statement 

ETLEN 

Time  of  last  enable/disable 

Updated  by  both  the  ENABLE  and 
DISABLE  statements 

ETTEN 

Total  time  enabled 

Calculated  by  DISABLE  statement 
as  (CL0CK3  - ETLEN)  + ETTEN 

ENDSA 

Number  of  disables 

Updated  by  DISABLE  statement 

ETTDSA 

Total  time  disables 

Calculated  by  ENABLE  statement 
as  (CL0CK3  - ETLEN)  + ETTDSA 
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Table  C.2.2-3 

IPSS  Request  Stream  Statistics  - Definitions 


Statistic  Type 

Specific  Statistic  Name 

Definition 

General 

Number  Exogenous  requests  generated 

EXGEN 

•Number  Exogenous  requests  terminated 

EXTRM 

Arrival  time 

•First  generated  Exogenous  event  arrival 
time 

EFARR 

•Mean  interarrival  time 

(ELARR  - EFARR)/EXGEN 

•Last  arrival  time 

ELARR 

Enable/Disable 

•Number  of  enables 

ENEN 

•Total  time  enabled 

ETTEN 

•Mean  enable  time 

(ETTEN/EXEN) 

•Number  of  disables 

ENDSA 

•Total  time  disabled 

ETTDSA 

•Mean  disable  time 

(ETTDSA/ENDSA) 

•Statistic  currently  exists  in  IPSS  models 

All  of  the  proposed  new  statistics  in  the  area  of  I/O  activity  were 
concerned  with  the  concept  of  locality.  Statistics  were  proposed  at  the 
Data  Set  level  and  within  the  Data  Set,  by  File,  Extent,  Volume,  Cylinder 
and  Track,  and  at  the  Area  level,  and  within  Area  by  Segment  and  by 
Volume.  All  of  these  statistics  are  to  be  gathered  by  the  GET  ADDRESS 
statement.  Major  modifications  however,  will  be  required  to  the  existing 
IPSS  code  supporting  the  IPSS  GET  ADDRESS  Built-In  Procedure  in  order  to 
gather  the  required  data.  The  purpose  of  these  statistics  is  to  measure 
the  degree  of  hardware  and  file  management  level  I/O  activity  that  occurred 
during  the  current  model.  Measures  of  I/O  routine  performance  are  collected 
by  I/O  routine  type,  by  associated  access  mechanism,  and  by  referenced  Data 
Set  and  File.  Statistics  showing  the  degree  of  locality  of  consecutive 
logical  and  physical  references  by  Data  Set  and  Area  were  also  proposed. 

A second  set  of  statistics  of  similar  intent  was  proposed  for  the 
IPSS/DBS  subsystem.  Since  these  statistics  are  closely  associated  with 
other  I/O  activities,  the  decision  was  made  to  delay  the  examination 
of  this  class  of  statistics  until  the  IPSS/DBS  subsystem  was  operational. 
However,  the  I/O-related  statistics  are  defined  in  Table  C2.3  for  report 
completeness. 
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Table  C.2;3  IPSS  I/O  Activity  Statistics 


Currently  Proposed 

Statistics  Type Specific  Statistic Available  Extension  Disposition 

I/O  Invocations  Number  of  calls  X 

(By  I/O  Statement)  Percent  zero-time  calls  X 

Mean  time  per  call  X 

Mean  time  for  non-zero 
calls  X 

Standard  deviation  of 

time  per  call  X 

Standard  deviation  of 
time  per  call 
(excluding  zero-time 
calls)  X 

(Mean  and  standard 
deviation  of  various 
physical  attributes, 
i.e.,  cylinders  crossed, 
characters  read,  etc.)  X 


I/O  Invocations 
(By  Access 
Mechanism) 


I/O  Invocations 
(By  Data  Set  and 
File) 


By  I/O  type  for  each 
Access  Mechanism: 

Number  of  calls  X 

Number  of  zero-time 
calls  X 

Percent  zero-time  calls  X 

Mean  routine  time  X 

Mean  routine  time  (ex- 
cluding zero-time 
calls)  X 

Standard  deviation  of 
mean  routine  time  X 

Standard  deviation  of 


mean  routine  time  (ex- 
cluding zero  time  calls)  X 

By  I/O  type  for  each  Data 
Set  and  File: 


Number  of  calls  X 

Number  of  zero-time  calls  X 

Percent  of  zero-time  calls  X 

Mean  routine  time  X 

Mean  routine  time  (ex- 
cluding zero-time  calls)  X 

Standard  deviation  of 
mean  routine  time  X 

Standard  deviation  of 
mean  routine  time  (ex- 
cluding zero-time  calls)  X 


— U. 


* 
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Table  C.2.3  IPSS  I/O  Activity  Statistics  (Continued) 


Statistics  Type 


Specific  Statistic 


Currently  Proposed 

Available  Extension  Disposition 


i 


Locality 
(Data  Set) 
(Conditional ) 


Local ity 
(Area) 

(Conditional ) 


By  Data  Set: 

Number  of  consecutive 
references  for  each 
file 
By  File: 

Number  of  consecutive 
references  for  each 
Extent 
By  Extent: 

Number  of  consecutive 
references  to  the  same 
Volume 
By  Volume: 

Number  of  consecutive 
references  to  the  same 
cyl inder 

Average  number  of 
cylinders  crossed 
By  Cylinder: 

Number  of  consecutive 
references  to  the  same 
track 

Average  number  of  tracks 
crossed 
By  Track: 

Number  of  consecutive 
references  to  the 
same  block 
Average  number  of 
blocks  crossed 

By  Area: 

Total  number  of  references 
to  area 

Number  of  consecutive  refer- 
ences to  same  area 
Average  number  of  consecutive 
references 

Average  length  between 
consecutive  references  in 
terms  of  reference  units 
By  Segment: 

Total  number  of  references 
to  segment 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


NE 

NE 

NE 

NE 

NE 

NE 

NE 

NE 

NE 

ME 

NE 

NE 

NE 

NE 


4 
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Table  C.2.3  IPSS  I/O  Activity  Statistics  (Continued) 


Statistics  Type 

Currently 

Specific  Statistic  Available 

Proposed 

Extension 

Disposition 

Number  of  consecutive 
references  to  same 
segment 

X 

NE 

Average  number  of 
consecutive  references 

X 

NE 

Average  length  between 
consecutive  references 
in  terms  of  reference 
units 

X 

NE 

By  Volume: 

Number  of  consecutive 
references  to  same 
volume 

X 

NE 

Average  number  of 
consecutive  references 

X 

NE 

Average  length  between 
consecutive  references 
in  terms 

X 

NF 

♦Disposition  codes  used  in  this  table  are: 


NE:  Not  evaluated 


- 


***** 


•gal?:'- * 
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An  extensive  number  of  queueing  statistics  are  currently  gathered 
during  an  IPSS  model's  execution.  Several  additional  extensions  to 
these  statistics  were  proposed  and  evaluated.  These  are  now  being 
incorporated  into  the  IPSS  statistics  generation  procedures.  Table 
C.2.4-1  identifies  both  the  existing  and  proposed  statistics  and  the 
result  of  the  evaluative  effort.  The  purpose  of  Table  C. 2.4-2  is  to 
identify  the  specific  data  for  these  statistics.  Table  C.2.4-3  provides 
definitions  for  the  statistics. 


Statistics  Type 


Busy  Period 


Idle  Period 
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Table  C.2.4-1  IPSS  Queueing  Statistics 


Specific  Statistic 


Currently 

Available 


Total  number  of  busy 
periods 

Number  of  zero  time  busy 
periods 

Percent  zero  time  busy 
periods  . 

Total  busy  time 
Percent  busy 
Mean  length  of  busy 
peri od 

Mean  length  of  busy  period 
(excluding  zero  time 
periods) 

Standard  deviation  for 
non-zero  time  busy 
periods 

Maximum  length  of  a 
busy  period 

Minimum  (non-zero)  length 
of  a busy  period 
Length  of  the  current 
busy  period 

Total  number  of  idle 
periods 

Number  of  zero-time 
idle  periods 
Percent  zero-time 
idle  periods 
Total  idle  time 
Percent  idle 
Mean  length  of  an  idle 
period 

Mean  length  of  an 

idle  period  (excluding 
zero-time  periods) 
Standard  deviation  for 
non-zero  time  idle 
periods 

Maximum  length  of  an 
idle  period 
Minimum  (non-zero) 
length  of  an 
idle  period 


Proposed 

Extension  Disposition 


EU-DP 


EU-DP 

EU-DP 


EU-DP 


EU-DP 


EU-DP 


EU-DP 

EU-DP 


EU-DP 


Table  C.2.4-1 


IPSS  Queueing  Statistics  (Continued) 


Currently 

Proposed 

Statistics  Type 

Specific  Statistic 

Available 

Extension 

Disposition 

Queue  Length 

Mean  length 

X 

(Durinq  a Busy 

Maximum  length 

X 

Period) 

Current  length 

Standard  deviation 

X 

of  mean  length 

X 

Queue 

Total  number  of 

queue  entries 

Total  number  of 

X 

completed  queue 
entries 

X 

Number  of  zero- time 
queue  entries 

Percent  of  zero-time 

X 

queue  entries 

Mean  queue  transit 

X 

time 

Mean  queue  transit 

X 

(excluding  zero- 
time transit) 

X 

Standard  deviation  of 

non- zero  time 
queue  transit 

X 

Maximum  transit  time 
Minimum  (non-zero) 

X 

EU-DP 

transit  time 

X 

EU-DP 

Disposition  codes  used  for  this  Table  are: 

EU-DP:  Examined,  found  useful  - Defined  not  implemented  but  useful  in  paper 

model 


I 
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Table  C.2.4-2  IPSS  Queueing  Statistics  - Required  Model  Statements 


Variable  Name* 

Description  of  the  Variable 

Method  of  Data  Collection 

QCNCE 

Current  number  of  concurrent 
elements  in  queue 

Update  by  queue  and  Depart 
queue  Statement 

QMXNCE 

Maximum  number  of  current 
concurrent  elements  in  queue 

Update  by  queue  statement 
queue 

QSNCE 

Sum  of  number  of  concurrent 
elements  in  queue 

Updated  by  Depart  queue 
statement 

QSNCES 

Sum  of  (number  of  concurrent 
elements  in  queue)**2 

Updated  by  queue  and  Depart 
queue  statement 

QSQE 

Total  number  of  queue  elements 

Update  by  queue  statement 

QSZQE 

Total  number  of  zero-time  queue 
elements 

Updated  by  Depart  queue 
statements 

QSTT 

Sum  of  time  per  transaction 

Updated  by  Depart  queue 
statement 

QSTTS 

Sum  of  (time  per  trans)**2 

Updated  by  Depart  queue 
statement 

QCTI 

Cumulative  Time  integral 

Updated  by  queue/Depart 
queue  statement 

QTQDQ 

Time  of  last  occurrence  of 
queue  or  Depart  queue 
invocation 

Updated  by  Queue  and  Depart 
queue  statement 

QSBP 

Total  number  of  busy  periods 

Updated  by  queue  statement 

QSBPL 

Sum  of  length  of  busy  periods 

Updated  by  Depart  queue 
statement 

QSBPLS 

Sum  of  (length  of  busy 
periods)**2 

Updated  by  Depart  queue 
statement 

QSIP 

Number  of  idle  periods 

Updated  by  Depart  queue 
statement 

QSIPL 

Sum  of  length  of  time  for 
each  idle  period 

Update  by  queue  statement 
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Table  C.2.4-2 

IPSS  Queueing  Statistics  - Required  Model  Statements  (Continued) 

Variable  Name* 

Description  of  the  Variable 

Method  of  Data  Collection 

QSIPLS 

Sum  of  (length  of  idle 
periods)**2 

Updated  by  Queue  statement 

QTBIP 

Time  of  last  Busy  or  Idle 
period  start 

Updated  by  Queue  statement 
and  Depart  Queue 

QSZBP 

Number  of  zerotime  busy 
periods 

Updated  by  Queue  statement 

QSZIP 

Number  of  zerotime  idle  periods 

Updated  by  Depart  Queue 
statement 

QMNBPL 

Minimum  non-zero  busy  period 
length 

Updated  by  Depart  Queue 
statement 

QMXBPL 

Maximum  busy  period  length 

Updated  by  Depart  Queue 
statement 

QCBPL 

Length  of  current  busy  period 

Updated  by  Depart  Queue 
statement 

QMNIPL 

Minimum  non- zero  idle  period 
length 

Updated  by  Queue  statement 

QMXIPL 

Maximum  idle  period  length 

Updated  by  Queue  statement 

QCIPL 

Length  of  current  idle  period 

Updated  by  Queue  statement 

QMXTT 

Maximum  transit  time  per 
transaction 

Updated  by  Depart  Queue 
statement 

QMNTT 

Minimum  non-zero  transit 
time  per  transaction 

Updated  by  Depart  Queue 
statement 

*A11  data  are  stored  in  the  statistics  area  associated  with  the  designated 

facility. 


Table  C.2.4-3  IPSS  Queueing  Statistics  - Definitions 


Statistic  Type Specific  Statistic 

Busy  Period  Total  number  of  busy  periods 

Number  of  zerotime  busy  periods 
%zero  time  busy  periods 
Total  Busy  time 
%busy 

Mean  length  of  busy  period 

Standard  deviation  of  mean 
length 

Mean  length  of  nonzero  time 
busy  periods 

Standard  deviation  of  nonzero 
time  busy  periods 

Maximum  length  of  a busy  period 
Minimum  non-zero  length 
Length  of  current  busy  period 
Idle  Period  Total  number  of  idle  periods 

Number  of  zerotime  idle  periods 
%zero  time  idle  periods 
Total  idle  time 
%i  dl  e 

Mean  length  of  idle  period 

Standard  deviation  of  mean 
length 


Definition 

QSBP 

QSZBP 

(QSZBP/QSBP)*100 

QSBPL 

(QSBPL/CL0CK3)*100 

(QSBPL/QSBP) 

( (QSBP*QSBPLS-QSBPL**2)/ 
(QSBP*(QSBP-1 ) ) )**0. 5 

(QSBPL/ (QSBP-QSZBP)) 

( ( (QSBP-QSZBP )*QSBPLS-QSBPL**2 ) 
/((QSBP-QSZBP)*(QSBP-QSZBP-1 ) ) ) 
**0.5 

QMXBPL 

QMNBPL 

QCBPL 

QSIP 

QSZIP 

(QSZI P/QS I P ) *1 00 
QSIPL 

(QSIPL/CL0CK3)*100 

(QSIPL/QSIP) 

( ( (QSIP-QSIPLS)-QSIPL**2) 

/ ( QS I P* ( QS IP- 1 ) ) )**0. 5 


Table  C. 

Statistic  Type 


Queue  Length 

Queue 

Transit  Time 
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.4-3  IPSS  Queueing  Statistics 

Specific  Statistic 

Mean  length  of  nonzero  time 
idle  periods 

Standard  deviation  of  nonzero 
time  idle  periods 

Maximum  length  of  an  idle  period 

Minimum  nonzero  length 

Length  of  current  idle  period 

Mean  length 

Maximum  length 

Current  length 

Standard  deviation  of  mean 
length 

Total  number  of  queue  entries 

Total  number  of  completed 
queue  entries 

Number  of  zerotime  queue 
entries 

%zerotime  queue  entries 

Mean  transit  time  per 
transaction 

Mean  nonzero  time  per 
transaction 

Standard  deviation  of  mean 
transaction  time 


Definition 

(QSIPL/(QSIP-QSZIP) ) 

( ( (QSIP-QSZIP)*QSIPLS-QSIPL**2) 

/( (QSIP-QSZIP)*(QSIP-QSZIP-1 ) 

) )**0. 5 

QMXIPL 

QMNIPL 

QCIPL 

(QSNCE/QSQE) 

QMXNCE 

QCNCE 

. 

( (QSQE*QSNCES-QSNCE**2) 
/(QSQE*(QSQE-1 ) ) )**0. 5 

QSQE 

QSQE  - QCNCE  = QSCQE 
QSZQE 

( QSZQE/QSQE ) *1 00 
(QSTT/(QSQE-QCNCE)) 

(QSTT/ (QSCQE-QSZQE ) ) 

( (QSCQE*QSTTS-QSTT**2) 
/(QSCQE*(QSCQE-1 )))**0.5 


- Definitions  (Continued 


Statistic  Type 


Specific  Statistic 


Definition 


Standard  deviation  of  mean 
non-zerotime  transactions 

Maximum  transit  time 
Minimum  nonzero  transit  time 


( ( (QSCQUE-QSZQE)*QSTTS-QSTT**2) 

/( (QSCQE-QSZQE)*(QSCQE-QSZQE-1 ) 
) )**0. 5 

QMXTT 

QMNTT 


e 

D 

a 

a 

a 

o 


C.2.5  IPSS  Utilization  Statistics 


An  IPSS  model  generates  utilization  statistics  on  user  defined 
modeled  facilities.  Several  extensions  to  these  statistics  were  proposed 
and  evaluated  in  the  research.  Table  C.2.5-1  identifies  all  IPSS  utiliza 
tion  statistics,  whether  current  or  proposed  and  their  desposition  after 
evaluation.  Table  C.2.5-2  identifies  the  means  for  their  generation  and 
Table  C.2.5-3  contains  their  definitions. 


Table  C.2.5-1  IPSS  Utilization  Statistics 


Currently 

Statistic  Type Specific  Statistics Available 


Busy  Period 


Idle  Period 


Concurrency 


Total  number  of  busy  periods  X 

Number  of  zero  time  busy 
periods  X 

Percent  zero  time  busy  periods  X 

Total  busy  time  X 

Percent  busy  X 

Mean  length  of  busy  period  X 


Mean  length  of  busy  period 
(excluding  zero  time 
periods) 

Standard  deviation  for 
nonzero  time  busy  periods 
Maximum  length  of  a busy 
period 

Minimum  (non-zero)  length 
of  a busy  period 
Length  of  the  current  busy 
period 


Total  number  of  idle  periods  X 

Number  of  zero  time  idle 
periods  X 

Percent  zero- time  idle 
periods  X 

Total  idle  time  X 

Percent  idle  X 

Mean  length  of  an  idle 
period  X 


Mean  length  of  an  idle 
period  (excluding  zero- 
time periods) 

Standard  deviation  for 
nonzero  time  idle  periods 
Maximum  length  of  an  idle 
period 

Minimum  (non-zero)  length  of 
an  idle  period 
Length  of  the  current  idle 
period 


Mean  level  of  concurrency  X 
Maximum  level  of  concurrency  X 
Current  level  of  concurrency  X 
Standard  deviation  of  mean 

level  of  concurrency  X 


Proposed 

Extension  Disposition 


X 

X 

X 

X 

X 


EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-DP 


X 

X 

X 

X 

X 


EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-DP 


Table  C.2.5-1  IPSS  Utilization  Statistics  (Continued) 


Currently 

Proposed 

ij 

Statistic  Type 

Specific  Statistics 

Available 

Extension 

Disposition 

Seizure 

Total  number  of  seizures 
Total  number  of  completed 

X 

■ I 

1 1 

seizures 

X 

Number  of  zero-time 
seizures 

Percent  zero-time 

X 

seizures 

X 

Mean  seizure  time 

Mean  seizure  time  (ex- 

X 

eluding  zero-time 
seizures) 

X 

Standard  deviation  of  non- 
zero time  seizures 

Maximum  length  of  a 

X 

i ] 

seizure 

X 

EU-DP 

Minimum  (non-zero)  length 

1 

of  a seizure 

X 

EU-DP 

i 

• 1 

Disposition  codes  used  in  this  table  are: 


EU-DP:  Examined,  found  useful  - defined,  not  implemented  but  useful  in 

paper  model. 
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Table  C.2.5-2  IPSS  Utilization  Statistics  - Required  Model  Statement 

Variable  Name* Description  of  the  Variable Method  of  Data  Collection 


UCNCS 

Current  number  of  Concurrent 
seizures 

Updated  by  Seize/Release 
statements 

UMXNCS 

Maximum  number  of  current 
concurrent  seizures 

Updated  by  Seize  statement 

USNCS 

Sum  of  number  of  concurrent 
seizures 

Updated  by  Seize/Release 
statement 

USNCSS 

Sum  of  (number  of  concurrent 
seizures)**2 

Updated  by  Seize/Release 
statement 

USSEZ 

Total  number  of  seizures 

Updated  by  Seize  statement 

USZSEZ 

Total  number  of  zero-time 
seizures 

Updated  by  Release  statement 

USTT 

Sum  of  time  per  transaction 

Updated  by  Release  statement 

USTTS 

Sum  of  (time  per  trans)**2 

Updated  by  Release  statement 

UCTI 

Cumulative  Time  Integral 

Update  by  Seize  and  Release 
statements 

UTSR 

Time  of  last  seize  or  release 

Updated  by  Seize  and  Release 
statements 

US8P 

Total  number  of  busy  periods 

Update  by  Seize  statement 

USBPL 

Sum  of  length  of  busy  periods 

Update  by  Release  statement 

USBPLS 

Sum  of  (length  of  busy 
periods)**2 

Updated  by  Release  statement 

USIP 

Number  of  idle  periods 

Updated  by  Release  statement 

US  I PL 

Sum  of  length  of  idle  periods 

Updated  by  Seize  statement 

USIPLS 

Sum  of  (length  of  idle 
periods)**2 

Updated  by  Seize  statement 

UTBIP 

Time  of  last  Busy  or  idle 
period  start 

Updated  by  Seize  and 

Release  statement 

I 


Ll 


Table  C.2.5-2  IPSS  Utilization  Statistics  - Required  Model  Statement  (Continued) 


Variable  Name* Description  of  the  Variable Method  of  Data  Collection 


USZBP 

Number  of  zerotime  busy 
periods 

Updated 

by 

Release  statement 

USZIP 

Number  of  zerotime  idle 
periods 

Updated 

by 

Seize  statement 

UMNBPL 

Minimum  non-zero  busy  period 
length 

Updated 

by 

Release  statement 

UMXBPL 

Maximum  busy  period  length 

Updated 

by 

Release  statement 

UCBPL 

Length  of  current  busy  period 

Updated 

by 

Release  statement 

UMNIPL 

Minimum  non-zero  idle  period 
length 

Updated 

by 

Seize  statement 

UMXIPL 

Maximum  idle  period  length 

Updated 

by 

Seize  statement 

UCIPL 

Length  of  current  idle  period 

Updated 

by 

Seize  statement 

UMXTT 

Maximum  transit  time  per 
transaction 

Updated 

by 

Release  statement 

UMNTT 

Minimum  non-zero  transit 
time  per  transaction 

Updated 

by 

release  statement 

♦All  data  are  stored  in  the  statistics  area  associated  with  the  designated  facility. 
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Table  C.2.5-3  IPSS  Utilization  Statistics  - Definitions 


Statistic  Type 
Busy  Period 


Idle  Period 


Specific  Statistic Definition 


Total  number  of  busy  periods 
Number  of  zerotime  busy  periods 
%zero  time  busy  periods 
Total  busy  time 
%busy 

Mean  length  of  busy  period 

Standard  deviation  of  mean 
length 

Mean  length  of  non-zero  time 
busy  periods 

Standard  deviation  of  non-zero 
time  busy  periods 

Maximum  length  of  a busy  period 
Minimum  non-zero  length 
Length  of  current  busy  period 
Total  number  of  idle  periods 
Number  of  zero  time  idle  periods 
%zero  time  idle  periods 
Total  idle  time 
fcidle 

Mean  length  of  idle  period 

Standard  deviation  of  mean 
length 


USBP 

USZBP 

(USZBP/USBP)*100 

USBPL 

(USBPL/CL0CK3)*100 

(USBPL/USBP) 

( ( (USBP-USBPLS ) -USBPL**2 ) 
/(USBP*(USBP-1 ) ) )**0. 5 

(USBPL/(USBP-USZBP) ) 

( ( (USBP-USZBP)*USBPLS-USBPL**2) 
/((USBP-USZBP)*(USBP- 
USZBP-1 ) ) )**0. 5 

UMXBPL 

UMNBPL 

UCBPl 

USIP 

USZIP 

(USZIP/USIP)*100 

USIPL 

(USIPL/CL0CK3)*100 

(USIPL/USIP) 

( (USIP*USIPLS-USIPL**2) 
/(USIP*(USIP-1 ) ) )**0.  5 


Table  C.2.5-3  IPSS  Utilization  Statistics  - Definitions  (Continued) 


Statistic  Type 


Concurrency 


Seizures 


Transit  Time 


Specific  Statistic Definition 

Mean  length  of  non-zero  time 
idle  periods 


Standard  deviation  of  non-zero 
time  idle  periods 

Maximum  length  of  an  idle  period 
Minimum  non-zero  length 
Length  of  current  Idle  period 
Mean  level 
Maximum  level 
Current  level 

Standard  deviation  of  mean  level 

Total  number  of  seizures 

Total  number  of  completed 
seizures 

Number  of  zero-time  seizures 

%zero-time  seizures 

Mean  transit  time  per  trans- 
action 

Mean  non-zero  time  per 
transaction 

Standard  deviation  of  mean 
transaction  time 

Standard  deviation  of  mean  non- 
zero-time transactions 


( US  I PL/  ( US  I P-USZ  IP)) 

( ( (USIP-USZIP)*USIPLS-USIPl**2) 
/((USIP-USZIP)*(USIP- 
USZIP-1 ) ) )**0. 5 

UMXIPL 

UMNIPl 

UCIPL 

(USNCS/USSEZ) 

UMXNCS 

UCNCS 

( (USSEZ*USNCSS-USNCS**2) 

/ (USSEZ*( USSEZ- 1 ) ) )**0.  5 

USSEZ 

USCSEZ  = USSEZ  - UCNCS 

USZSEZ 

(USZSEZ/USSEZ)*100 

(USTT)/USCSEZ 

(USTT/(USCSEZ-USZSEZ) ) 

( (USCSEZ*USTTS-USTT**2) 
/(USCSEZ*(USCSEZ-1 ) ) )**0.  5 

( ( (USCSEZ-USZSEZ)*USTTS-USTT**2) 
/( (USCSEZ-USZSEZ)*(USCSEZ- 
USZSEZ-1 ) ) )**0. 5 
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Table  C.2.5-3  IPSS  Utilization  Statistics  - Definitions  (Continued 

Statistic  Type Specific  Statistic Definition 

Maximum  transit  time  UMXTT 

Minimum  non- zero  transit  time  UMNTT 
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C.2.6  IPSS  Wait  Statistics 


These  statistics  measure  the  degree  to  which  individual  transactions 
were  delayed  until  specific  system  resources  attained  appropriate  status. 
They  are  similar  to  types  of  statistics  gathered  for  Queueing  Statistics. 
IPSS  automatically  collects  these  statistics  as  a by-product  of  the 
following  IPSS  Built-in  procedures: 

1.  Wait  Facility  Status, 

2.  Wait  Service  Complete, 

3.  Wait  I/O  Complete, 

4.  Wait  Semaphore, 

5.  Wait  Access  Path,  and 

6.  Wait  Signal. 

The  effect  of  these  built-in  procedures  is  to  suspend  the  execution 
of  a service  until  the  Identified  condition  is  met.  The  statistics  for 
each  are  the  same.  Only  the  WAIT  FACILITY  STATUS  definitions  are  described 
in  this  section.  Table  C2.6-1  identifies  all  the  IPSS  Wait  Statistics, 
Table  C2.6-2  the  means  for  their  operation  and  Table  C2.6-3  their 
definitions. 
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Table  C.2.6-1  IPSS  Wait  Statistics 


Statistic  Type 


Busy  Period 


Idle  Period 


Specific  Statistics 


Currently 

Available 


Proposed 

Extension  Disposition 


Wait  Chain  Length 
Characteristics 


1 

L * 


Total  number  of  busy  periods  X 

Number  of  zero-time  busy 

periods  X 

Percent  zero-time  busy 
periods  X 

Total  busy  time  X 

Percent  busy  X 

Mean  length  of  a busy  period  X 

Mean  length  of  a busy  period 
(excluding  zero-time 
periods) 

Standard  deviation  for  non- 
zero time  busy  periods 
Maximum  length  of  a busy 
period 

Minimum  (non-zero)  length  of 
a busy  period 

Length  of  the  current  busy 
period 

Total  number  of  idle  periods  X 

Number  of  zero-time  idle 
periods  X 

Percent  zero- time  idle 
periods  X 

Total  idle  time  X 

Percent  idle  X 

Mean  length  of  an  idle  period  X 

Mean  length  of  an  idle  period 
(excluding  zero-time 
periods) 

Standard  deviation  for  non- 
zero time  idle  periods 
Maximum  length  of  an  idle 
period 

Minimum  (non-zero)  length  of 
an  idle  period 
Length  of  the  current  idle 
period 

Mean  length  X 

Maximum  length  X 

Current  length  X 

Standard  deviation  of  mean 

length  X 


X 

X 

X 

X 

X 


X 

X 

X 

X 

X 


EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-DP 


Number  of  zero-time 
entries 

Percent  zero- time  entries 
Mean  time  in  chain 
Mean  time  in  chain  (ex- 
cluding zero-time 
entries) 

Standard  deviation  of 
mean  time  non-zero-time 
entries 

Maximum  time  in  chain 
Minimum  (non-zero)  time 
in  chain 


X 

X 

X 


X 

X 


EU-DP 

EU-DP 


Disposition  codes  used  in  this  table  are: 


EU-DP:  Examined,  found  useful  - defined,  not  implemented  but  useful  in 

paper  model . 


: 
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Table  C.2.6-2  IPSS  Wait  Statistics  - Required  Model  Statements 


Variable  Type* 
WCNE 

WMXNCE 

WSNCE 

WSNCES 

WSWCE 

WSZWCE 

WSTT 

WSTTS 

WCTI 

WTWFSS 

WSBP 

WSBPL 

WSBPLS 

WSIP 
WSIPL 
WSIPLS 

WTBIP 


Description  of  the  Variable Method  of  Data  Collection 

Current  number  of  Concurrent 
wait  chain  elements 

Maximum  number  of  current 
concurrent  wait  chain  elements 

Sum  of  number  of  concurrent 
wait  chain  elements 

Sum  of  (number  of  concurrent 
wait  chain  elements)**2 

Total  number  of  wait  chain 
elements 

Total  number  of  zero-time 
wait  chain  elements 

All  statistics  are  maintained 

Sum  of  time  per  transaction  by  the  Wait  statements 

Sum  of  (time  per  trans)**2 

Cumulative  Time  integral 

Time  of  last  wait  start  or 
wait  end 

Total  number  of  busy  periods 

Sum  of  length  of  busy  periods 

Sum  of  (length  of  busy 
periods)**2 

Number  of  idle  periods 

Sum  of  length  of  idle  periods 

Sum  of  (length  of  idle 
periods)**2 

Time  of  last  Busy  or  Idle 
period  start 


’f=±z 
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Table  C.2.6-2  IPSS  Wait  Statistics  - Required  Model  Statements  (Continued) 


Variable  Type* 


Description  of  the  Variable 


Method  of  Data  Collection 


WSZBP 

Number  of  zerotime  busy  periods 

WSZDP 

Number  of  zerotime  idle  periods 

WMNBPL 

Minimum  non-zero  busy  period 
length 

WMXBPL 

Maximum  busy  period  length 

WCBPL 

Length  of  current  busy  period 

All  statistics  are  maintained 
by  the  Wait  Statement 

WMNIPL 

Minimum  non-zero  idle  period 
length 

WMXIPL 

Maximum  idle  period  length 

WCIPL 

Length  of  current  idle  period 

WMXTT 

Maximum  transit  time  per 
transaction 

WMNTT 

Minimum  non-zero  transit 
time  per  transaction 

*A11  are  stored  in  the  statistics  area  associated  with  the  designated  facility. 


Statistics  Type 


Specific  Statistic 


Definitions 


1 


. I 


4 


Busy  Period 


Idle  Period 


Total  number  of  busy  periods 
Number  of  zerotime  busy  periods 
Hero  time  busy  periods 
Total  busy  time 
%busy 

Mean  length  of  busy  period 


Standard  deviation  of  mean 
length 


Mean  length  of  non-zero  time 
busy  periods 


Standard  deviation  of  non-zero 
time  busy  periods 


Maximum  length  of  a busy  period 
Minimum  non-zero  length 
Length  of  current  busy  period 
Total  number  of  idle  periods 
Number  of  zerotime  idle  periods 
Herotime  idle  periods 
Total  idle  time 
Xldle 

Mean  length  of  idle  period 


Standard  deviation  of  mean 
length 

Mean  length  of  non-zero  time 
idle  periods 


WSBP 

WSZBP 

(WSZBP/WSBP)*100 

WSBPL 

(WSBPL/CL0CK3)*1 00 
(WSBPL/WSBP) 


( (WSBP*WSBPLS-WSBPL**2) 

/ (WSBP*(WSBP-1 ) ) )**0. 5 


(WSBPL/ (WSBP-WSZBP) 


( ( (WSBP-WSZBP)*WSBPLS- 
WSBPL**2)/( (WSBP-WSZBP) 
*(WSBP-WSZRP-1 ) ) )**0. 5 


WMXBPL 

WMNBPL 

WCBPL 

WSIP 

WSZIP 

(WSZIP/WSIP)*100 

WSIPL 

(WSIPL/CLOCK3)*100 

(WSIPL/WSIP) 


((WSIP*WSIPLS-WSIPL**2) 

/ (WSIP* (WS IP-1 ) ) )**0. 5 


(WSIPL/ (WSIP-WSZ IP)) 


] 


a 


] 

] 

] 

:i 


Table  C.2.6-3  IPSS  Wait  Statistics  - Definitions  (Continued) 


Statistics  Type 


Chain  Length 


Chain 


Transit  Time 


Specific  Statistic Definitions 


Standard  deviation  of  non-zero 
time  idle  periods 

Maximum  length  of  an  idle  period 

Minimum  non-zero  length 

Length  of  current  Idle  period 

Mean  length 

Maximum  length 

Current  length 

Standard  deviation  of  mean 
length 

Total  number  of  wait  chain 
entries 

Total  number  of  completed 
chain  entries 

Number  of  zero-time  entries 

^.zero-time  chain  entries 

Mean  transit  time  per  trans- 
action 

Mean  non-zero  time  per 
transaction 

Standard  deviation  of  mean 
transaction  time 

Standard  deviation  of  mean  non- 
zero-time transactions 

Maximum  transit  time 
Minimum  non-zero  transit  time 


( ( (WSIP-WSZIP)*W$IPLS-WSIPL**2 ) 
/((WSIP-WSZIP)*(WSIP-WS7IP-1 ) 
))**0.5 

WMXIPL 

WXNIPL 

1C  I PL 

(WSNCE/WSWCE) 

WMXNCE 

WCNCE 

( (WSWCE*WSNCES-WSNCE**2) 
/(WSWCE*(WSWCF-1 )))**0.5 

WSWCE 

WSCCE  = WSWCE  - WCNCE 

WSZWCE 

(WSZWCE/WSWCE)*100 

(WSTT/WSCCE)*100 

(WSTT/( WSCCE -WSZWCE ) ) 

( (WSCCE*WSTTS-WSTT**2 ) 

/ (WSCCE* (WSCCE-1 ) ) )**0. 5 

( ( (WSCCE-WSZWCE)*WSTTS- 
WSTT**2)/( (WSCCE -WSZWCE) 
*(WSCCE-WS7.WCE-1)))**0.5 

OMXTT 

WMNTT 
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C.2.7  IPSS  Service  Related  Statistics 

IPSS  Exogenous  and  Endogenous  services  are  modeler-defined  model 
components  representing  information  system  processes.  These  processes 
could  be  manual  or  automated.  IPSS  provides  the  modeler  with  over  100 
statements  in  addition  to  the  use  of  all  of  ANSI  Fortran  to  define  these 
services.  In  the  current  IPSS,  services  are  treated  the  same  as  other 
acquirable  resources  for  statistic  gathering  purposes. 

In  the  proposal  a number  of  additional  statistics  specific  to 
services  were  proposed.  The  purpose  of  these  new  statistics  is  to 
characterize  service  performance  in  a more  meaningful  manner.  This  is 
accomplished  in  the  following  two  ways: 

A.  Modeler  Explicit  Statistics 

Three  new  sets  of  IPSS  statements  permit  the  modeler  to  divide 
overall  service  time  into  three  segments; 

1.  Queue  Time  - time  which  a request  for  service  spends  in  a 
service  maintained  queue  waiting  for  its  service  to 
commence, 

2.  Acquire  Time  - time  spent  by  the  service  acquiring  the 
resources  needed  to  service  a request,  and 

3.  Service  Time  - time  spent  by  the  service  servicing  the 
request. 

These  statistics  are  generated  only  when  explicitly  requested  by  the 
modeler  through  the  employment  respectively  of  the  following  IPSS 
statement  pairs: 

1 . MARK  QUEUE  START  - MARK  QUEUE  END 

2.  MARK  ACQUIRE  START  - MARK  ACQUIRE  END 

3.  MARK  SERVICE  START  - MARK  SERVICE  END 

B.  Modeler  Implicit  Statistics 

The  purpose  of  these  statistics  is  to  allocate  a service's 
time  to  subordinate-services.  The  IPSS  translator  will  identify 


all  Endogenous  services  (modeler  defined  or  IPSS  Built-in)  requested 
by  a modeler  defined  service.  Statistics  on  subservice  performance 
will  be  gathered  and  displayed  with  the  calling  service.  These 
statistics  show  total  service  time  for  the  invoked  service  with 
respect  to  the  invocations  by  the  requestor  service  and  total  time. 

The  requestor  service  was  delayed  wait  for  the  requested  service  to 
complete  processing.  These  statistics  are  automatically  generated 
by  the  REQUEST  SERVICE  - WAIT  SERVICE  statements. 

Table  C.2.7-1  identifies  the  specific  statistics  generated.  Tables 
C.2.7-2  and  C.2.7-3  specify  the  IPSS  mechanisms  used  in  their  generation. 


Table  C.2.7-1 


IPSS  Service  Related  Statistics 


Statistic  Type 
Execution 


Queue  Time 


Acquire  Time 


Service  Time 


Service  by  Service 
(For  each 
Service  invoked 
by  a parent 
service) 


Currently  Proposed 

Specific  Statistics Available Extension  Disposition* 


Total  number  of  executions  X EU-DP 

Percent  zero-time  X EU-DP 

Mean  execution  time  X EU-DP 

Mean  non-zero  execution  time  X EU-DP 

Total  number  of  periods  X EU-DP 

Percent  zero-time  X EU-DP 

Mean  period  length  X EU-DP 

Mean  non-zero  period  length  X EU-DP 

Mean  percent  of  execution 

time  X EU-DP 

Mean  non-zero  percent  of 

execution  time  X EU-DP 

Total  number  of  periods  X EU-DP 

Percent  zero-time  X EU-DP 

Mean  period  length  X EU-DP 

Mean  non-zero  period 

length  X EU-DP 

Mean  percent  of  execution 

time  X EU-DP 

Mean  non-zero  percent  of 

execution  time  X EU-DP 

Total  number  of  periods  X EU-DP 

Percent  zero-time  X EU-DP 

Mean  period  length  X EU-DP 

Mean  non-zero  period 

length  X EU-DP 

Mean  percent  of  execution 

time  X EU-DP 

Mean  non-zero  percent  of 

execution  time  X FU-DP 

Total  number  of  invocations  X EU-DP 

Percent  zero-time  invocations  X EU-DP 

Mean  time  per  invocation  X EU-DP 

Mean  time  per  invocation 

(excluding  zero-time  X EU-DP 

invocations) 

Total  number  of  Wait 

Service  Completes  X EU-DP 


Table  C.2.7-1 


IPSS  Service  Related  Statistics  (Continued) 


Statistic  Type 


Currently  Proposed 

Specific  Statistics Available Extension  Disposition* 


Percent  zero-time  Waits 
Mean  time  per  Wait 
Mean  time  per  Wait  (excluding 
zero-time  Waits) 


X El' -DP 

X EU-DP 

X EU-DP 


♦Disposition  codes  used  in  this  table  are: 

EU-DP:  Examined,  found  useful  - defined,  but  not  implemented 
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Table  C.2.7-2  IPSS  Service  Related  Statistics  - Required  Model  Statistics 


Variable  Type 


Description  of  the  Variable 


Method  of  Data  Collection 


The  following  variables  identify  storage  locations  in  the  fixed  statistics 
area  associated  with  each  modeler  defined  Exogenous  and  Endogenous  Service 


SCUMT 


SCUMQ 


SNZAC 


SCUMAC 


SCUMS 


Total  number  of  executions 


Total  number  of  zero-time 
executions 

Cumulative  execution  time 
Number  of  queue  periods 


Number  of  zero-time  queue 
periods 

Cumulative  queue  period 
time 

Number  of  acquire  periods 


Number  of  zero  time 
acquire  periods 

Cumulative  acquire  period 
time 

Number  of  service  periods 


Number  of  zero  time  periods 

Cumulative  service  period 
time 


Updated  by  REQUEST  SERVICE 
Statement 

Updated  by  WAIT  RETURN*  statement 


Update  by  TERMINATE*  statement 

Updated  by  MARK  QUEUE  START 
statement 


Updated  by  MARK  QUEUE  END, 
MARK  ACQUIRE  START,  MARK 
SERVICE  START  or  TERMINATE 
statements 

Updated  by  MARK  ACOUIRE  START 
statement 


Updated  by  MARK  ACQUIRE  END, 

MARK  SERVICE  START  or  TERMINATE 
statements 


Updated  by  MARK  SERVICE  START 
statement 


Updated  by  MARK  SERVICE  END 
or  TERMINATE  statements 


The  following  variables  identify  storage  locations  in  the  variable  part  of 
the  statistics  area.  These  are  replaced  for  each  subordinate  service 
requested  by  a service.  (Note:  intermediate  statistics  are  kept  in  the 
transactions  created  for  a requested  service  until  the  transaction  is 
terminated. ) 


Total  number  of  invocations 
of  Service  A 


Updated  by  REQUEST  SERVICE 
statement 


Table  C .2.7-2 

IPSS  Service  Related  Statistics  - 

Required  Model  Statistics  (Continued) 

Variable  Type 

Description  of  the  Variable 

Method  of  Data  Collection 

ssnzia 

Total  number  of  zero-time 
invocations  of  Service  A 

Update  by  TERMINATE  statement 

sstmia 

Total  execution  time 

Update  by  TERMINATE  statement 

ssnwa 

Total  number  of  Wait  Service 

Update  by  WAIT  SERVICE 

Complete  statement 

ssnzwa 

Total  number  of  zerotime 

Updated  by  WAIT  RETURN  statement 

SSTWSa 

Total  Wait  service  time 

Updated  by  WAIT  RETURN  statement 

♦These  statements  are  internal  to  IPSS  and  not  available  to  the  modeler. 
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Table  C.2.7-3  IPSS  Service  Related  Statistics  - Definitions 


Statistics  Type 
Execution 


Queue  Time 


Acquire  Time 


Specific  Statistic 

Total  number  of  executions 

Percent  zero-time 

Mean  execution  time 

Mean  non-zero  time 
execution  time 

Total  number  of  queue  periods 

Percent  zero-time 

Mean  period  length 

Mean  non-zero  tine 
period  length 

Mean  percent  of 
execution  time 

Mean  non-zero  % of 
non-zero  execution  time 

Total  number 

Percent  zero-time 

Mean  length 

Mean  non-zero  length 


Mean  % of  execution  time 

Mean  non-zero  % of  non-zero 
execution  time 


Definitions 


( SNZT/SNT ) *1 00 
SAVT  = (SCUMT/SNT) 

SAVTX  = (SCUMT/(SNT  - SNZT) ) 


( SNZQ/SNQ ) *1 00 
SAVQ  = (SCUMQ/SNO) 

SAVZQ  = (SCUMQ/ (SNQ  - SNZQ)) 


SAVQ/ SAVT 


SAVQZ/SAVTX 


(SNZAC/SNAC)*1 00 

SAVAC  = (SCNMAC/SNAC) 

SAVACX  = (SCUMAC/(SNAC 
SNZAC) ) 

(SAVAC/SAVT)*1 00 
(SAVACX/SAVTX)*100 


Service  Time 


Total  number 


Percent  zero-time 
Mean  length 


( SNZS/SNS )*1 00 
SAVS  = (SCUMS/SNS) 


I ■■■■ 


I 
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Table  C.2.7-3  IPSS  Service  Related  Statistics  - Definitions  (Continued) 


Statistics  Type 

Specific  Statistic 

Definitions 

Mean  non-zero  length 

SAVSX  = (SCUMS/ (SMS  - SNZS)) 

Mean  % execution  time 

(SAVS/SAVT)*1 00 

Mean  non-zero  % of 

non-zero  execution  time 

(SAVSX/SAVTX)*100 

Subservice  Behavior 
for  Requestor 

Total  number  of  invocations 

ssnia 

Service 

Percent  zero-time 

(ssnzia/ssnia)*ioo 

Mean  time  per  invocation 

(SSTMIa/SSNIa) 

Mean  time  per  non-zero 
time  execution 

(SSTMIa/(SSNIa  - SSNZ i A ) ) 

Total  number  of  WAIT 

SERVICE  COMPLETES 

SSNWa 

Percent  zero  time  Waits 

($SNZWa/SSNWa)*100 

Mean  time  per  Wait 

(SSTWa/SSNWa) 

Mean  time  per  non-zero 
time  Wait 

(SSTWa/(SSNWa  - SSNZWa)) 

« 


■I 
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C.2.8  IPSS  Task  and  Activity  Statistics 


These  statistics  provide  insight  into  the  service  activity  subordinate 
to  a specific  task,  where  a Task  is  a modeler  defined  facility  activated 
as  part  of  the  execution  of  a Exogenous  and  Endogenous  service.  A Task 
is  assumed  to  be  comprised  of  a linear  combination  of  one  or  more  modeler 
defined  activities  which  are  identified  as  part  of  the  Task  declaration. 

A modeler  defines  an  activity  by  associating  an  activity  name  with  an 
endogenous  service.  Statistics  are  gathered  for  a Task  by  gathering 
statistics  for  its  activities.  This  occurs  in  the  following  two  step 
process: 

1.  The  Task  is  explicitly  activated  via  the  INITIATE  TASK  statement. 

2.  Statistics  are  automatically  gathered  for  each  Endogenous  service 
which 

a.  is  subordinate  to  the  inservice  containing  the  INITIATE 
TASK  statement,  and 

b.  has  been  identified  as  an  activity  associated  with  the 
Task. 

The  statistics  gathering  continues  until  the  TERMINATE  TASK  statement 
is  executed. 

Table  C.2.8-1  identifies  the  statistics  to  be  gathered.  However, 
the  actual  collection  mechanism  to  be  used  within  an  IPSS  model  has  not 
yet  been  defined. 
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Table  C. 2.8-1  IPSS  Task  and  Activity  Statistics 


Currently 

Statistic  Type Specific  Statistics Available 

By  Task  — General  Total  number  of  tasks 

initiated 

Total  number  of  tasks 
completed 

Total  number  of  tasks  still 
in  execution 

Mean  time  per  task 
initiation 


Proposed 

Extension  Disposition * 

ij 

X EU-IM 

X EU-IM 

X EU-IM 

X FU-IM 


By  Activity  -- 
Within  Task  -- 
Task  Initiation 
Statistics 


Activity 

Invoke  Statistics 


Total  number  of  invocations 
by  task 

Mean  total  activity 
processing 

Mean  total  queue  time  per 
task  initiation 
Percent  queue  time  of 
processing  time 
Mean  total  activity  acquire 
time  per  task  initiation 
Percent  acquire  time  of 
processing  time 
Mean  total  activity  service 
time  per  task  initiation 
Percent  service  time  of 
processing  time 
Mean  processing  time  per 
invocation  by  task 
Mean  activity  queue  time  per 
invocation  by  task 
Percent  queue  time  of  pro- 
cessing time  per  invocation 
Mean  activity  acquire  time 
per  invocation  by  task 
Percent  acquire  time  of  pro- 
cessing time  per  invocation 
Mean  activity  service  time 
per  invocation  by  task 
Percent  service  time  of  pro- 
cessing time  by  task 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


EU-IM 

EU-IM 

EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-IM 

EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-DP 

EU-DP 


I 

I 

■ 


i 


i 


: 


♦Disposition  codes  used  in  this  table  have  the  following  meanings: 
EU-IM: 

EU-OP: 


-1— - 
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C3.  IPSS  EXTENSIONS  TO  CHARACTERIZE  COMPUTER  NETWORKS 


The  standard  IPSS  and  the  IPSS/DBS  have  been  designed  to  operate 
as  independent  simulators.  However,  an  integrated  model  capability  is 
required  in  order  to  characterize  a complete  system.  In  the  IPSS  this 
capability  was  achieved  by  permitting  the  concurrent  execution  of  two 
asynchronous  simulation  processes  which  have  the  ability  to  communicate. 
Once  this  cability  was  defined,  it  was  possible  to  extend  the  mechanism 
to  accommodate  any  number  of  asynchronous  processes. 

The  purpose  of  this  section  is  to  describe  the  mechanism  to  be  used 
which  will  permit  the  modeling  of  information  processing  system  networks. 
For  this  discussion  a mode  is  assumed  to  be  an  individual  model  containing 
IPSS  components: 


Component 


Number  Permitted 


Request  Streat 
System  Resources 
Storage  Structure 
Data  Base  Access 
Data  Structure 


or 

or 


1 

1* 


or  1** 
or  1* 


or  1*** 


♦Either  the  System  Resources  or  Data  Base  Access  Component  must  be 
present.  Both  can  also  be  present  at  each  mode. 


♦♦Storage  Structure  Component  can  be  present  only  when  the  System 
Resources  Component  is  also  present. 


♦♦♦Data  Structure  Component  can  be  present  only  when  the  Data  Base 
Access  Component  is  also  present. 


A network  is  comprised  of  multiple  nodes  which  communicate  by  initiating 
requests  for  services  to  another  node.  These  services  requests  are 
treated  the  same  as  exogenous  requests  generated  by  a node's  request 
stream.  To  establish  a network  the  modeler  defines  a multiple  facility 


1 


1 

i 


Currently,  in  order  to  simulate  a computer  network,  all  nodes  of  the 
network  have  to  be  combined  together  to  form  a single  facility  pool 
consisting  of  at  most  one  of  each  of  the  following  components:  system 
resource  component,  storage  structure  component,  request  stream  component 
and  model  director  component.  Since  the  above  approach  does  not 
facilitate  independent  testing  of  each  node  or  evaluating  the  interaction 
between  nodes,  a modeling  structure  which  allows  multiple  facility  pools 
is  needed.  The  basic  structure  of  the  IPSS  nucleus  which  directs  model 
execution  is  given  in  Figure  C3.1-la.  In  order  to  consider  multiple 
facility  pools,  this  structure  will  have  to  be  modified  to  that  shown 
in  Figure  C3 . 1 -1 b . In  the  multiple  facility  pool  configuration,  the 
nucleus  consists  of  three  drivers: 


1 . Model  Driver 

The  function  of  the  model  driver  is  the  same  as  in  the  case  of  a 
single  facility  pool.  It's  basic  function  is  to  start  and  terminate 
the  simulation  drivers. 

2.  Global  Simulation  Driver 

The  global  simulation  driver  controls  the  FEQ  (Future  Events  Queue) 
and  the  simulation  clock.  All  future  events  generated  by  the 

t 

different  facility  pools  are  combined  together  into  a single  FEQ 

so  as  to  provide  correct  simulated  time  synchronization  between  j 

the  facility  pools.  The  global  simulation  driver  has  a priority 

list  that  is  used  to  determine  which  local  simulation  driver  has 

control . 

3.  Local  Simulation  Driver 

Each  facility  pool  has  a local  simulation  driver  which  controls  its 
corresponding  CEQ  (Current  Event  Queue).  Once  a local  simulation 
\ driver  is  given  control,  it  retains  control  until  either  (i)  a 

transaction  has  to  be  placed  in  a different  CEQ  or  (ii)  a transac- 
tion has  to  be  placed  in  the  FEQ.  In  these  cases,  the  local  driver 
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returns  control  to  the  global  driver  which  has  the  responsibility 
for  placing  the  transaction  into  the  FEQ  or  calling  the  appropriate 
local  nucleus  to  insert  a transaction  into  its  CEQ.  If  placement 
is  in  a CEQ  with  higher  priority  than  the  currently  active  one,  the 
interrupt  flag  is  set.  The  currently  active  nucleus  again  resumes 
processing  its  active  transaction  until  its  processing  is  suspended. 

If  the  interrupt  flag  is  set,  control  is  given  to  the  local  driver 
with  the  higher  priority  via  the  global  nucleus,  otherwide  the 
current  driver  continues  with  its  next  transaction.  The  process 
continues  until  all  the  CEQ's  are  empty  at  which  time  the  clock  is 
advanced  to  the  next  most  imminent  departure  time  in  the  FEQ.  One 
or  more  transactions  with  this  time  are  then  moved  to  their 
corresponding  CEQ  and  control  is  given  to  the  nucleus  with  highest 
priority  and  the  process  begins  a new. 

C3.2  Changes  to  IPSS  Simulation  Nucleus 

In  order  to  accommodate  the  multiple  facility  pool  structure,  a 
number  of  changes  had  to  be  made  to  the  IPSS  nucleus  and  system  subroutines. 


1.  The  IPSS  definitional  tables  (e.g.,  $T0C,  $LBL,  $DIR,  $DEF)  of 
the  individual  facility  pools  have  to  be  combined  together  to 
form  a single  set  of  tables. 

2.  To  avoid  naming  conflicts  between  facility  pools,  a global 
interface  routine  is  needed  to  invoke  the  currently  implemented 
local  interface  routines. 

3.  The  system  subroutines  (e.g.,  EQUATE,  INVOKE)  that  handle  intra- 
facility pool  communications  have  to  be  modified  to  handle 
inter-facility  pool  communications. 

Detailed  programming  changes  to  IPSS  are  given  below. 


Changes  to  the  IPSS  Fortran  System  Subroutines  to  Handle 
Multiple  Facility  Pools 

(A)  The  following  procedures  are  to  be  modified: 

1.  $FDEF 

This  procedure  has  to  be  modified  so  that  it  will  accept  base 
pointers  to  the  definitional  tables  as  parameters.  A procedure 
for  searching  the  System  Resources  and  Data  Base  Access  $DEF 
tables  through  $T0C,  $LBL  and  $DIR  has  to  be  added  to  this 
procedure. 

2.  $EQUAT 

This  procedure  has  to  be  modifed  so  that  ’l  accept 
definitional  table  addresses  and  bases  for  me  qu?ted  components 
as  input  parameters. 

3.  $CREAT 

This  procedure  has  to  be  modified  so  that  both  the  Facility's 
Pool  ID  and  Driver  ID  are  stored  In  the  created  transaction. 

4.  $GENER,  $GADR , $SYSEX2,  SSEEK,  $EXINT 

All  calls  to  the  interface  routine  are  to  be  modified. 

5.  $LINK,  $UNLINK,  $INSRT,  $REM0V 

All  these  procedures  have  to  be  modified  to  accept  multiple 
CEQ's. 

6.  SDRIVR 

This  procedure  has  to  be  modified  to  handle  multiple  CEQ's.  The 
driver  should  automatically  interchange  base  for  the  definitional 
table  when  a new  CEQ  is  selected.  All  calls  to  interface 
routines  should  be  modified.  Also,  all  calls  to  initialization 
routines  have  to  be  modified  so  that  all  Facility  Pool/Driver- 
relative  components  are  initialized. 

7.  SDVINT,  $AB0RT 

Parameter  lists  are  to  be  deleted  from  these  procedures  and 
appropriate  COMMON'S  should  be  added. 
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8.  All  statistical  routines  are  to  be  modified  so  that  separate 
statistics  will  be  printed  for  each  facility  pool. 

9.  All  procedures  that  use  the  Create  Data  Set  ($CD$)  arrays  have 
to  be  changed. 

10.  Ail  procedures  that  use  absolute  addresses  for  accessing  the 

definitional  table  have  to  be  changed  so  that  they  use  relative 
addresses  in  the  base  table. 

(B)  The  following  procedures  to  be  added. 

1 . $BL0C 

When  the  Facility  Pool  ID  and  Driver  ID  are  given,  this . procedure 
will  search  through  the  base  table  to  identify  the  bases  to  be 
used  for  the  local  simulation  driver. 

2.  $SUPEQ 

This  procedure  handles  all  inter-facility  pool  equates  and  makes 
use  of  $EQUAT  to  resolve  all  intra-facility  pool  equates. 

3.  $ INIT 

This  procedure  initializes  all  endo  and  exo  services  with  the 
facility  pool  and  driver  ID's.  The  endo  and  exo  service 
definitions  are  found  by  searching  through  $T0C,  $LBL  and  $DIR. 

4.  $ INVEX 

This  procedure  handles  the  invoking  of  an  Exo  service  in  another 
facility  pool.  Basically,  this  procedure  facilitates  inter- 
facility pool  communications. 

(C)  The  following  Fortran  tables  and  statements  are  to  be  generated  by 
the  language  parsers. 

1.  CEQ  Table 

This  table  will  be  used  by  the  flobal  simulation  driver  to 
determine  the  priority  of  the  CEQ's. 
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$PRTY 

$FPID 

$DRIVR 

$CBEG 

$CEND 

• 

• 

• 

• 

• 

$PRTY:  Priority  of  the  CEQ 

$DPIF:  Facility  Pool  ID 

$DRIVR:  type  of  driver 

1.  if  SR,  RS  or  SS  component  driver 

2.  if  DBA  or  DT  component  driver 

$CBEG:  beginning  addresses  of  CEQ's  (initialized  to  zero's) 

$CEND:  ending  addresses  of  CEQ's  (initialized  to  zero's) 

2.  BASE  Table 

This  table  stores  the  bases  used  for  addressing  the  definitional 
tables. 


$FPID  $CMPNT  $$T0C  $$LBL  $$DIR  $$DEF  $CDS  $NEVNT 


$FPID:  Facility  Pool  ID 
$CMPNT:  Component  ID 

type  =1  if  SR  component 
type  = 2 if  RS  component 
type  = 3 if  SS  component 
type  = 4 if  DBA  component 
type  = 5 if  DT  component 
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$$TOC:  list  of  bases  for  $T0C 

$$  LBL:  list  of  bases  for  $LBL 

$$DIR:  list  of  bases  for  $dir 

$$DEF:  list  of  bases  for  $DEF 

$CDS:  list  of  bases  for  create  data  set  array 

$NEVNT:  number  of  events  that  has  occurred  in  the  associated 
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facility  pool. 

5.  The  following  interface  routine  will  be  generated  for  each 
(facility  pool,  driver)  pair. 

SUBROUTINE  $xxxxx  (TYPE,  SYSIND,  INDX1 , INDX2 ,*) 

INTEGER  TYPE,  SYSIND,  INDX1 , INDX2 
GO  TO  (100,  200,  300,  400),  TYPE 
50  RETURN  1 

100  CALL  $CFPR  (SYSIND,  &50) 

RETURN 

200  CALL  SYSER  (INDX2,  INDXT,  &50) 

RETURN 

300  CALL  $DBPR  (SYSIND,  650) 

RETURN 

400  CALL  $EXPR  (SYSIND,  &50) 

RETURN 

END 

Where  xxxxx  Is  a unique  name  generated  for  each  (facility 
pool , driver)  pair. 

4.  The  following  global  interface  routine  is  generated  for  the 
model  pool . 

SUBROUTINE  $SUPER  (FPID,  DRIV,  TYPE,  SYSIND,  INDX1 , XINDX2,*) 
INTEGER  FPID,  DRIV,  TYPE,  SYSIND 
INTEGER  INDX1 , INDX2,  I 
GO  TO  9999 

1 CALL  $xxxxx  (TYPE,  SYSIND  INDXl , INDX2 
RETURN 


